Nikita Prokopov’s bloghttps://tonsky.me/blog/fall-of-native/ Article argues that Claude is not an Electron app not because LLMs can’t do it, but because there are no advantages left for native <div class="page" morss_own_score="5.040783034257749" morss_score="9.475412009522767"> <article class="content" morss_own_score="8.869257950530034" morss_score="44.91471249598458"> <h1>Claude is an Electron App because we’ve lost native</h1> <p>In <a href="https://www.dbreunig.com/2026/02/21/why-is-claude-an-electron-app.html">“Why is Claude an Electron App?”</a> Drew Breunig wonders:</p> <blockquote> <p>Claude spent $20k on an agent swarm implementing (kinda) a C-compiler in Rust, but desktop Claude is an Electron app.</p> <p>If code is free, why aren’t all apps native?</p> </blockquote> <p>And then argues that the answer is that LLMs are not good enough yet. They can do 90% of the work, so there’s still a substantial amount of manual polish, and thus, increased costs.</p> <p>But I think that’s not the real reason. The real reason is: native has nothing to offer.</p> <p>API-wise, native apps lost to web apps a long time ago. Native APIs are terrible to use, and OS vendors use everything in their power to make you not want to develop native apps for their platform. That explains the rise of Electron before LLM times, but it’s also a problem that LLMs solve now: if that was a real barrier to developing native apps, it doesn’t exist anymore.</p> <p>Then there’re looks and consistency. Some time ago, maybe in the late 90s and 2000s, native was ahead. It used to look good, it was consistent, and it all actually worked: the more apps used native look and feel, the better user experience was across apps (which we used to call programs). </p> <p>These days, though, native is as bad as the web, if not worse. Consistency is basically out the window. Anything can look like anything, buttons have no borders, contrast doesn’t exist, and neither do conventions. Apple, for example, seems to place traffic lights and corner radius by vibes rather than by any measurable guidelines.</p> <p>Looks could be good, but they also can be bad, and then you are stuck with platform-consistent, but generally bad UI (Liquid Glass ahem). It changes too often, too: the app you made today will look out of place next year, when Apple decides to change look and feel yet again. There’s no native look anymore.</p> <p>Theoretically, native apps can integrate with OS on a deeper level. This sounds nice, but what does that mean in practice? There are almost no good interoperable file formats; everything is locked inside individual apps, most services moved to the web, and OSes dropped the ball for making a good shared baseline. You can integrate with OS-provided calendar, but you can’t do it with web calendar. Well, you can, of course, but it’s easier on the web; native doesn’t help with it at all.</p> <p>Finally, the last hope of people longing for native is performance. They feel that native apps will be faster. Well, they can, but it doesn’t mean they will. Web apps can be faster, too, but in practice, nobody cares. There’s no technical reason why <a href="https://tonsky.me/blog/js-bloat/">Slack needs to load 80 MiB</a> just to show 10 channel names and 3 messages on a screen. The web is not the problem here! It’s a choice to be bad. What makes you think it’ll be different once the company decides to move to native?</p> <p>Don’t get me wrong: writing this brings me no joy. I don’t think web is a solution either. I just remember good times when native did a better-than-average job, and we were all better for using it, and it saddens me that these times have passed.</p> <p>I just don’t think that kidding ourselves that the only problem with software is Electron and it all will be butterflies and unicorns once we rewrite Slack in SwiftUI is not productive. The real problem is a lack of care. And the slop; you can build it with any stack.</p> <p><span>March 3, 2026</span><span>·</span><span>Discuss on</span> <a href="https://news.ycombinator.com/item?id=47235430">Hacker News</a> <a href="https://lobste.rs/s/r8kjli/claude_is_electron_app_because_we_ve_lost">Lobsters</a></p> </article> <p>Hi!</p> <p>I’m Niki. Here I write about programming and UI design <a href="https://tonsky.me/subscribe/">Subscribe</a></p> <p>I consult on all things Clojure: web, backend, Datomic, DataScript, performance, etc. Check out my <a href="https://github.com/tonsky">Github</a> and get in touch <a href="mailto:niki@tonsky.me">niki@tonsky.me</a></p> </div> Tue, 03 Mar 2026 00:00:00 UTChttps://tonsky.me/talks/#2026-01-15<div class="talks" morss_own_score="2.8825654923215898" morss_score="24.88256549232159"> <h2><a href="https://t.me/ilyabirman_channel/11098">На Маке нет никаких шкафов</a></h2> <p>С Ильей Бирманом провожаем Алана Дая, вспоминая, в чём состоят достижения Мака, Джобса и ХИГа (но и Винду добрым словом тоже вспоминаем).</p> <h2><a href="https://podlodka.io/440">Почему компьютеры не умеют считать?</a></h2> <p>Как компьютеры представляют числа – от int и float до NaN, BigInt, decimals и комплексных. Прошлись по всему числовому зоопарку: обсудили, зачем нужны разные типы, где они подводят, и почему 0.1 + 0.2 ≠ 0.3 – не баг, а особенность.</p> <h2><a href="https://t.me/tfeat/132">Datomic: самая рок-н-рольная БД</a></h2> <p>Чем Datomic отличается от других баз данных и почему иногда остутствие оптимизатора лучше, чем его присутствие</p> <h2>Local-first is not going to win, but that’s okay</h2> <p>We’ll explore the complexities of traditional stack (db-server-frontend), develop a theory of software evolution: which systems succeed and why. Then we’ll see how local-first fits into it and which local-first-adjacent practices are making software development easier and therefore are doomed for success (or not?)</p> <h2>Clojure workflow with Sublime Text</h2> <p>A deep overview of Clojure Sublimed, Socket REPL, Sublime Executor, custom color scheme, clj-reload and Clojure+.</p> <p>We discuss many usability choices, implementation details, and broader observations and insights regarding Clojure editors and tooling in general. </p> <h2><a href="https://t.me/ilyabirman_channel/11098">Мир стал строго лучше</a></h2> <p>С Ильей Бирманом обсуждаем, как меньше критиковать, и — разумеется — критикуем Эпл изо всех сил.</p> <h2><a href="https://t.me/tfeat/108">Nikitonsky про современные редакторы кода</a></h2> <p>Каким должен быть редактор кода в 2024 году? Почему Vim морально устарел, а IDEA, кажется, сдает позиции? Популярность Zed, минимализм SublimeText, гибкость Emacs и многое другое в новом выпуске.</p> <h2>Clj-reload: A smarter way to reload code</h2> <p>In Clojure, we all love the REPL. We love playing with our code and seeing results applied live without ever restarting the app.</p> <p> But in any project, there comes a time when your state becomes more complex than a simple set of functions. Evaluating the buffer does not cut it anymore. What do you do?</p><p> In this talk, we’ll see how clj-reload can help, why it was created, and how it is better than tools.namespace.</p> <h2><a href="https://t.me/ilyabirman_channel/10261">Компьютеры не особо рассчитаны на людей</a></h2> <p>Илья рассказывает, как мы просрали многозадачность, а Никита ругает консольный интерфейс Гита.</p> <h2><a href="https://podlodka.io/364">Дата и время</a></h2> <p>Дата и время — не самый простой домен. То зимнее-летнее время, то часовые пояса не кратны часу. А что, если не надо привязываться к часовому поясу? Еще в чате распределенной команды написали, что митинг в 5PM, так когда подключаться? Как синхронизировать время с колонией на Марсе?</p> <h2><a href="https://t.me/ilyabirman_channel/9972">Красиво разлетаются брызги по твоей мисочке</a></h2> <p>обсудили, что две главные фичи нового Макоса, виджеты и видеообои, сделаны через жопу.</p> <h2>Как разрабатывают Open Source и ЧТО ЭТО ТАКОЕ</h2> <p>Что такое Open Source, как тут программировать и получать опыт, как зарабатывать и стоит ли вкатываться</p> <h2>Desktop GUI Made Easy</h2> <p>Introduction to Humble UI, a new JVM Clojure library for desktop GUI applications. Why is it needed, how is it implemented, how deep is the rabbit hole, who could it be useful to, and what can you build with it?</p> <h2><a href="https://t.me/ilyabirman_channel/9941">Ты явно хочешь гуй</a></h2> <p>Обсудили ещё деталей интерфейса текстового ввода, зачем люди пользуются терминалом и анимацию.</p> <h2><a href="https://t.me/ilyabirman_channel/9906">Ощущается как ненастоящие ёлочные игрушки</a></h2> <p>Выпуск про то, что в Эпле теряются даже те знания о дизайне, которые они же сами и принесли в мир.</p> <h2><a href="https://t.me/ilyabirman_channel/9883">Тексту положено быть быстрым</a></h2> <p>Простое и сложное, быстрое и небыстрое.</p> <h2>Escaping Software Disenchantment</h2> <p>Richard talks with Nikita Prokopov about some of the reasons he'd felt a sense of disenchantment with the direction of software in the past, and strategies he's developed for improving things in the future.</p> <h2><a href="https://podlodka.io/342">Рендеринг текста проклят</a></h2> <p>Преобразования, которые происходят с текстом для его отображения на экране</p> <h2><a href="https://podlodka.io/339">Кодировки текста</a></h2> <p>История развития, принципы работы, странные проблемы</p> <h2><a href="https://soundcloud.com/javaswag/e40">Подкаст Java Swag, эпизод 40</a></h2> <p>Разочарование в Java, простота Clojure и опенсорс проекты</p> <h2>Как мы попали в IT</h2> <p>Как влиять на технологии и делать значимый опенсорс</p> <h2>Clojure + UI = ❤️</h2> <p>Introducing Humble UI, a desktop UI framework for Clojure</p> <h2>Your frontend needs a database</h2> <p>Communication between frontend and backend should be handled by database</p> <h2><a href="https://soundcloud.com/clojurestream/sublimed-with-nikita-prokopov">Clojure Sublimed</a></h2> <p>Sublime Text setup for Clojure development</p> <h2>Мы обречены</h2> <p>Разочарование в софте, разочарование в Дюне Вильнева</p> <h2><a href="https://devzen.ru/episode-0331/">Подкаст DevZen, эпизод 331</a></h2> <p>Разработка IDE, какой она должна быть, какие они были за последние 50 лет, отзывчивость UI, тренды и идеи.</p> <h2><a href="https://soundcloud.com/vsapronov/my-obrecheny-open-source-govorim-s-nikitoi-prokopovym">Мы обречены — Open Source</a></h2> <p>Говорим про open source c Никитой Прокоповым.</p> <h2>SciCloj #18: Introducing Skija</h2> <p>What Skija is about, how does it work, what is it good for.</p> <h2><a href="https://changelog.com/podcast/401">The Changelog episode 401</a></h2> <p>The intersection of coding and fonts: coding fonts! Talking with The Changelog about Fira Code.</p> <h2><a href="https://soundcloud.com/clojurestream/s4-e4-rum-with-nikita-prokopov">ClojureScript podcast, s04e04</a></h2> <p>Rum With Nikita Prokopov</p> <h2><a href="https://devzen.ru/episode-0245/">Подкаст DevZen, эпизод 245</a></h2> <p>Обсуждаем физические принципы клавиатур, виды раскладок, как клавиатура приводит к RSI и как этого избежать, как правильно собрать свою клавиатуру.</p> <h2><a href="https://t.me/KgOfHedgehogs/509">Подкаст Высший Клик, эпизод 2</a></h2> <p>Обсуждаем эргономику клавиатур и отвечаем на <a href="https://tonsky.livejournal.com/321097.html">вопросы из комментариев.</a></p> <h2>Building My Own Clojure Tools</h2> <p>I’m using my own font, my own syntax grammar, my own color scheme, my own indentation rules. Why? Let’s explore what’s wrong with existing ones and how hard it is to build your own. Spoiler: not hard at all.</p> <p><a href="https://tonsky.me/talks/slides/2019.04%20Toronto.pdf">Slides</a></p> <h2><a href="https://soundcloud.com/defn-771544745/40-nikita-prokopov-aka-tonsky">Defn podcast, episode 40</a></h2> <p>Software disenchantment, DataScript, Rum, FiraCode and Flutter</p> <h2>Разочарование в программировании</h2> <p>Компьютеры стали бытовым прибором, начать программировать легче, чем когда-либо, сложнейшие вещи делаются просто и даже тривиально, написаны горы готового кода. К сожалению, у этого есть и обратная сторона — программы становятся большими, медленными, неуправляемыми, непонимаемыми.</p> <p><a href="https://tonsky.me/talks/slides/2018.10%20YouCon.pdf">Слайды</a></p> <h2><a href="https://www.therepl.net/episodes/5/">The REPL podcast, episode 5</a></h2> <p>Data synchronisation, the web after tomorrow, Datascript, Rum, software quality, and font ligatures.</p> <h2>Подкаст Run Loop, эпизод 4</h2> <p>Родился, вырос, написал AnyBar (и всё остальное)</p> <h2>REPL-driven development</h2> <p>Пропагандирую REPL</p> <h2><a href="https://music.yandex.ru/album/6842995/track/70282010">Подкаст Frontend Weekend, эпизод 55</a></h2> <p>С какой целью было создано столько блогов и шрифт Fira Code? Почему ЖЖ до сих пор живой? Почему предпочитаю фронтенд и HolyJS в частности?</p> <h2><a href="https://devzen.ru/episode-0193/">Подкаст DevZen, эпизод 193</a></h2> <p>Хорошие интерфейсы — хорошо, но и плохие не смертельно; error монады в динамических языках.</p> <h2>Обретение навыков</h2> <p>Пять стадий прокачки (новичок, продвинутый, компетентный, специалист, эксперт) в работе программистов, обучении, общении, спорах</p> <p><a href="https://tonsky.me/talks/slides/2018.10%20AppsConf.pdf">Слайды</a></p> <h2>Web, JavaScript и цирк с конями</h2> <p>О веб-разработке, веб-экосистеме и веб-будущем</p> <h2>Coherence: Conflict-free* DVCS</h2> <p>What if we use conflict-free text editing data structures (OT/CRDT) for version control?</p> <p><a href="https://tonsky.me/talks/slides/2017.10%20Vienna.pdf">Slides</a></p> <h2>Client and Server need to talk</h2> <p>Data sync problem space and solutions. GraphQL, Apollo, PouchDB, reactivity, Meteor, Firabase, event sourcing, conflict resolution, CRDTs</p> <p><a href="https://tonsky.me/talks/slides/2017.10%20Reactive.pdf">Slides</a></p> <h2>Совершенствуя Clojure</h2> <p>Как сделать Clojure код еще лучше. Организация кода, стиль, соглашения, читаемость, опасные конструкции</p> <p><a href="https://tonsky.me/talks/slides/2017.02%20Moscow%20Clojure%20Meetup.pdf">Слайды</a></p> <h2>How to approach modern web apps</h2> <p>High-level architecture overview of modern collaborative web apps. Data model, normalization, decoupling, client storages, data sync, event sourcing, optimistic UI, collaboration</p> <p><a href="https://tonsky.me/talks/slides/2016.12%20funcby.pdf">Slides</a></p> <h2>A Database for the Client</h2> <p>Short intro into <a href="https://github.com/tonsky/datascript">DataScript</a>, powerful client-side storage. Lightweight, relational, normalized, immutable, supports queries &amp; transaction log</p> <h2>Isomorphic Web Apps with Rum</h2> <p>History and philosophy behind <a href="https://github.com/tonsky/rum">Rum</a>, isomorphic Clojure/Script UI library. Simplicity, transparency, extensibility, server-side rendering</p> <p><a href="https://tonsky.me/talks/slides/2016.09%20clojureTRE.pdf">Slides</a></p> <h2><a href="https://devzen.ru/episode-0099/">Подкаст DevZen, эпизод 99</a></h2> <p>Обучение Clojure на <a href="http://ClojureCourse.by">ClojureCourse.by</a>, Ask Me Anything с Alan Kay и будущее языков программирования, React.js и работа с состоянием на фронтенде, Clojure.spec и property-based тесты, Websocket-ы в разных стеках.</p> <h2>Rum workshop</h2> <p>Capabilities, design philosophy, usage scenarios and lots of code examples</p> <h2>Данные на фронтенде</h2> <p>Анализ современных средств синхронизации данных. Проблематика, структура синхронизации, элементы архитектуры, плюсы и минусы Meteor, Firebase, PouchDB, Relay, Horizon, CRDT</p> <p><a href="https://tonsky.me/talks/slides/2016.06%20holyjs.pdf">Слайды</a></p> <h2>LambdaNsk митап</h2> <p>Что-то про Clojure</p> <h2>How immutability, functional programming, databases and reactivity change front-end</h2> <p>Do frontend apps need a storage? Why? DataScript data model, queries, transactions, database as a value, foundations for reliable data sync and reactive UIs</p> <p><a href="https://tonsky.me/talks/slides/2015.11%20reactive.pdf">Slides</a></p> <h2><a href="http://razbor-poletov.com/2015/10/episode-92.html">Подкаст Разбор полетов, эпизод 92</a></h2> <p>Clojure, ClojureScript, DataScript, Datomic</p> <h2>Web UI with Database in a Browser</h2> <p>Why web apps need a client-side data storage and how to apply <a href="https://github.com/tonsky/datascript">DataScript</a> to reactive single-page web applications</p> <p><a href="https://tonsky.me/talks/slides/2015.07%20polyconf.pdf">Slides</a></p> <h2>Функциональное программирование в браузере</h2> <p>Что такое чистые функции, разделение функций и данных, иммутабельность, ленивость в контексте веб-приложений</p> <p><a href="https://tonsky.me/talks/slides/2015.05%20FrontendConf/">Слайды</a></p> <h2>ToDo list in DataScript (webinar)</h2> <p>Creating ToDo app from scratch using DataScript and React.js</p> <h2>DataScript for Web Development</h2> <p>Overview of <a href="https://github.com/tonsky/datascript">DataScript</a> implementation and range of application architectures it enables</p> <h2><a href="http://tonsky.livejournal.com/297610.html">Как спорить о языках программирования</a></h2> <p>Что важно, что неважно, чеклист аргументов</p> <h2><a href="https://devzen.ru/episode-0012/">Подкаст DevZen, эпизод 12</a></h2> <p>ClojureCup, Transit, transducers, ClojureScript rationale, React</p> <h2>Функциональное программирование для всех</h2> <p>Чувствуете себя неуверенно в разговоре с матерыми коллегами на тему функциональных языков? Не знаете, что делает моноидальный эндофунктор? Хватит это терпеть.</p> <h2><a href="http://eax.me/eaxcast-s02e05/">Подкаст EaxCast, s02 e05</a></h2> <p>Streams (Mail 3.0 concept), Lambda architecture, Storm, Zookeeper</p> <h2>DataScript хэнгаут</h2> <p>Обзор, возможности, ответы на вопросы</p> <h2>Функциональный подход к JavaScript</h2> <p>Как ФП помогает во фронтенд-разработке</p> <h2><a href="http://2013.codefest.ru/lecture/53">Зачем вам нужна Clojure</a></h2> <p>Что такое, сильные/слабые стороны, применимость, опыт использования</p> <p><a href="https://tonsky.me/talks/slides/2013.03%20Codefest.pdf">Слайды</a></p> <h2>Ввеедние в Clojure часть 1</h2> <p>Открытая лекция в НГУ</p> <h2><a href="http://tonsky.livejournal.com/265218.html">Clojure @ Echo 00</a></h2> <p>Обзор, concurrency</p> <p><a href="https://tonsky.me/talks/slides/2012.06%20clojure%20at%20echo%2000.pdf">Слайды</a></p> <h2><a href="http://sibinetweek.ru/program/7/profitconf/prokopov_pravila-horoshego-tona-dlya-veb-prilozheniy">Правила хорошего тона для веб-приложений</a></h2> <p>Автоматизация, простота, человечность, доступность, внимание к деталям</p> <h2><a href="http://lib.custis.ru/1a2-philosophy-of-simplicity-prokopov">Философия простоты, или еретическая лекция о программировании</a></h2> <p>Как упростить и улучшить инструменты самих разработчиков</p> <p><a href="https://tonsky.me/talks/slides/2011.05%20ADDconf.pdf">Слайды</a></p> <h2>Основы проектирования интерфейсов</h2> <p>Базовые приемы улучшения интерфейса на случай, если в команде нет UI-дизайнера</p> </div> Thu, 15 Jan 2026 00:00:00 UTChttps://tonsky.me/blog/tahoe-icons/ Looking at the first principles of icon design—and how Apple failed to apply all of them in macOS Tahoe <div class="page" morss_own_score="5.757085020242915" morss_score="10.618508241216698"> <article class="content" morss_own_score="9.722846441947565" morss_score="642.273568003917"> <h1>It’s hard to justify Tahoe icons</h1> <p><em>Translations: <a href="https://nptr.cc/posts/2026-01/tonsky-tahoe/">Chinese 1</a> <a href="https://sspai.com/post/105394">Chinese 2</a> <a href="https://habr.com/ru/companies/ruvds/articles/985818/">Russian</a></em></p> <p>I was reading Macintosh Human Interface Guidelines <a href="https://dn721903.ca.archive.org/0/items/apple-hig/Macintosh_HIG_1992.pdf">from 1992</a> and found this nice illustration:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/hig_icons@2x.webp?t=1772581464"> </figure> <p>accompanied by explanation:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/hig_quote@2x.webp?t=1772581464"> </figure> <p>Fast forward to 2025. Apple releases macOS Tahoe. Main attraction? Adding unpleasant, distracting, illegible, messy, cluttered, confusing, frustrating icons (their words, not mine!) to every menu item:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/sequoia_tahoe_textedit@2x.webp?t=1772581464"><figcaption>Sequoia → Tahoe</figcaption> </figure> <p>It’s bad. But why exactly is it bad? Let’s delve into it!</p> <p>Disclaimer: screenshots are a mix from macOS 26.1 and 26.2, taken from stock Apple apps only that come pre-installed with the system. No system settings were modified.</p> <h1>Icons should differentiate</h1> <p>The main function of an icon is to help you find what you are looking for faster.</p> <p>Perhaps counter-intuitively, adding an icon to everything is exactly the wrong thing to do. To stand out, things need to be different. But if everything has an icon, nothing stands out.</p> <p>The same applies to color: black-and-white icons look clean, but they don’t help you find things faster!</p> <p>Microsoft used to know this:</p> <figure> <a href="https://tonsky.me"><img src="https://tonsky.me/blog/tahoe-icons/word@2x.webp?t=1772581464"></a> </figure> <p>Look how much faster you can find Save or Share in the right variant:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/menu_cleanup@2x.webp?t=1772581464"> </figure> <p>It also looks cleaner. Less cluttered.</p> <p>A colored version would be even better (clearer separation of text from icon, faster to find):</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/menu_cleanup_color@2x.webp?t=1772581464"> </figure> <p>I know you won’t like how it looks. I don’t like it either. These icons are hard to work with. You’ll have to actually design for color to look nice. But the principle stands: it is way easier to use.</p> <h1>Consistency between apps</h1> <p>If you want icons to work, they need to be <em>consistent</em>. I need to be able to learn what to look for.</p> <p>For example, I see a “Cut” command and <img src="https://tonsky.me/blog/tahoe-icons/scissors.svg?t=1772581464"> next to it. Okay, I think. Next time I’m looking for “Cut,” I might save some time and start looking for <img src="https://tonsky.me/blog/tahoe-icons/scissors.svg?t=1772581464"> instead.</p> <p>How is Tahoe doing on that front? I present to you: Fifty Shades of “New”:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/menu_new@2x.webp?t=1772581464"> </figure> <p>I even collected them all together, so the absurdity of the situation is more obvious.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/icons_new@2x.webp?t=1772581464"> </figure> <p>Granted, some of them are different operations, so they have different icons. I guess creating a smart folder is different from creating a journal entry. But this?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/menu_new_object@2x.webp?t=1772581464"> </figure> <p>Or this:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/icons_new_smart_folder@2x.webp?t=1772581464"> </figure> <p>Or this:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/icons_new_window@2x.webp?t=1772581464"> </figure> <p>There is no excuse.</p> <p>Same deal with open:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/menu_open@2x.webp?t=1772581464"> </figure> <p>Save:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/menu_save@2x.webp?t=1772581464"> </figure> <p>Yes. One of them is a checkmark. And they can’t even agree on the direction of an arrow!</p> <p>Close:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/menu_close@2x.webp?t=1772581464"> </figure> <p>Find (which is sometimes called Search, and sometimes Filter):</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/menu_find@2x.webp?t=1772581464"> </figure> <p>Delete (from Cut-Copy-Paste-Delete fame):</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/menu_delete@2x.webp?t=1772581464"> </figure> <p>Minimize window.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/menu_minimize@2x.webp?t=1772581464"> </figure> <p>These are not some obscure, unique operations. These are OS basics, these are foundational. Every app has them, and they are always in the same place. They shouldn’t look different!</p> <h1>Consistency inside the same app</h1> <p>Icons are also used in toolbars. Conceptually, operations in a toolbar are identical to operations called through the menu, and thus should use the same icons. That’s the simplest case to implement: inside the same app, often on the same screen. How hard can it be to stay consistent?</p> <p>Preview:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/preview@2x.webp?t=1772581464"> </figure> <p>Photos: same <img src="https://tonsky.me/blog/tahoe-icons/info_circle.svg?t=1772581464"> and <img src="https://tonsky.me/blog/tahoe-icons/info.svg?t=1772581464"> mismatch, but reversed ¯\_(ツ)_/¯</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/photos@2x.webp?t=1772581464"> </figure> <p>Maps and others often use different symbols for zoom:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/consistency_maps@2x.webp?t=1772581464"> </figure> <h1>Icon reuse</h1> <p>Another cardinal sin is to use the same icon for different actions. Imagine: I have learned that <img src="https://tonsky.me/blog/tahoe-icons/square_and_pencil.svg?t=1772581464"> means “New”:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/new_note@2x.webp?t=1772581464"> </figure> <p>Then I open an app and see <img src="https://tonsky.me/blog/tahoe-icons/square_and_pencil.svg?t=1772581464">. “Cool”, I think, “I already know what it means”:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/edit_address@2x.webp?t=1772581464"> </figure> <p>Gotcha!</p> <p>You’d think: okay, <img src="https://tonsky.me/blog/tahoe-icons/eye.svg?t=1772581464"> means quick look:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/quick_look@2x.webp?t=1772581464"> </figure> <p>Sometimes, sure. Some other times, <img src="https://tonsky.me/blog/tahoe-icons/eye.svg?t=1772581464"> means “Show completed”:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/show_completed@2x.webp?t=1772581464"> </figure> <p>Sometimes <img src="https://tonsky.me/blog/tahoe-icons/square_and_arrow_down.svg?t=1772581464"> is “Import”:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/import@2x.webp?t=1772581464"> </figure> <p>Sometimes <img src="https://tonsky.me/blog/tahoe-icons/square_and_arrow_down.svg?t=1772581464"> is “Updates”:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/update@2x.webp?t=1772581464"> </figure> <p>Same as with consistency, icon reuse doesn’t only happen between apps. Sometimes you see <img src="https://tonsky.me/blog/tahoe-icons/rectangle_pencil_ellipsis.svg?t=1772581464"> in a toolbar:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/form_filling_toolbar@2x.webp?t=1772581464"> </figure> <p>Then go to the menu <em>in the same app</em> and see <img src="https://tonsky.me/blog/tahoe-icons/rectangle_pencil_ellipsis.svg?t=1772581464"> means something else:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/autofill@2x.webp?t=1772581464"> </figure> <p>Sometimes identical icons meet in the same menu.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/save_export@2x.webp?t=1772581464"> </figure> <p>Sometimes next to each other.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/passwords@2x.webp?t=1772581464"> </figure> <p>Sometimes they put an entire barrage of identical icons in a row:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/photos_export@2x.webp?t=1772581464"> </figure> <p>This doesn’t help anyone. No user will find a menu item faster or will understand the function better if all icons are the same.</p> <p>The worst case of icon reuse so far has been the Photos app:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/photos_copy@2x.webp?t=1772581464"> </figure> <p>It feels like the person tasked with choosing a unique icon for every menu item just ran out of ideas.</p> <p>Understandable.</p> <h1>Too much nuance</h1> <p morss_own_score="6.0" morss_score="8.0">When looking at icons, we usually allow for slight differences in execution. That lets us, for example, understand that these <em>technically different</em> road signs mean the same thing:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/pedestrians.webp?t=1772581464"> </figure> <p>Same applies for icons: if you draw an arrow going out of the box in one place and also an arrow and the box but at a slightly different angle, or with different stroke width, or make one filled, we will understand them as meaning the same thing.</p> <p>Like, <img src="https://tonsky.me/blog/tahoe-icons/info_circle.svg?t=1772581464"> is supposed to mean something else from <img src="https://tonsky.me/blog/tahoe-icons/info_circle_fill.svg?t=1772581464">? Come on!</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/similar_i@2x.webp?t=1772581464"> </figure> <p>Or two letters A that only slightly differ in the font size:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/similar_font_size@2x.webp?t=1772581464"> </figure> <p>A pencil is “Rename” but a slightly thicker pencil is “Highlight”?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/similar_pencil@2x.webp?t=1772581464"> </figure> <p>Arrows that use different diagonals?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/similar_actual_size@2x.webp?t=1772581464"> </figure> <p>Three dots occupying ⅔ of space vs three dots occupying everything. Seriously?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/similar_sidebar@2x.webp?t=1772581464"> </figure> <p>Slightly darker dots?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/similar_quality@2x.webp?t=1772581464"> </figure> <p>The sheet of paper that changes meaning depending on if its corner is folded or if there are lines inside?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/similar_sheet@2x.webp?t=1772581464"> </figure> <p>But the final boss are arrows. They are all different:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/similar_arrows@2x.webp?t=1772581464"> </figure> <p>Supposedly, a user must become an expert at noticing how squished the circle is, if it starts top to right or bottom to right, and how far the arrow’s end goes.</p> <p>Do I care? Honestly, no. I could’ve given it a shot, maybe, if Apple applied these consistently. But Apple considers <img src="https://tonsky.me/blog/tahoe-icons/square_and_pencil.svg?t=1772581464"> and <img src="https://tonsky.me/blog/tahoe-icons/plus.svg?t=1772581464"> to mean the same thing in one place, and expects me to notice minute details like this in another?</p> <p>Sorry, I can’t trust you. Not after everything I’ve seen.</p> <h1>Detalization</h1> <p morss_own_score="7.0" morss_score="9.0">Icons are supposed to be easily recognizable from a distance. Every icon designer knows: small details are no-go. You can have them sometimes, maybe, for aesthetic purposes, but you can’t <em>rely</em> on them.</p> <p morss_own_score="7.0" morss_score="9.0">And icons in Tahoe menus are <em>tiny</em>. Most of them fit in a 12×12 pixel square (actual resolution is 24×24 because of Retina), and because many of them are not square, one dimension is usually even less than 12.</p> <p>It’s not a lot of space to work with! Even Windows 95 had 16×16 icons. If we take the typical DPI of that era at 72 dots per inch, we get a physical icon size of 0.22 inches (5.6 mm). On a modern MacBook Pro with 254 DPI, Tahoe’s 24×24 icons are 0.09 inches (2.4 mm). Sure, 24 is bigger than 16, but in reality, these icons’ area is 4 times as small!</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/dpi_comparison@2x.webp?t=1772581464"><figcaption>Simulated physical size comparison between 16×16 at 72 DPI (left) and 24×24 at 254 DPI (right)</figcaption> </figure> <p>So when I see this:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_zoom@2x.webp?t=1772581464"> </figure> <p>I struggle. I can tell they are different. But I definitely struggle to tell what’s being drawn.</p> <p>Even zoomed in 20×, it’s still a mess:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_zoomed@2x.webp?t=1772581464"> </figure> <p>Or here. These are three different icons:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_lists@2x.webp?t=1772581464"> </figure> <p>Am I supposed to tell plus sign from sparkle here?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_sparkle@2x.webp?t=1772581464"> </figure> <p>Some of these lines are half the pixel thicker than the other lines, and that’s supposed to be the main point:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_redact@2x.webp?t=1772581464"> </figure> <p>Is this supposed to be an arrow?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_original@2x.webp?t=1772581464"> </figure> <p>A paintbrush?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_paste@2x.webp?t=1772581464"> </figure> <p>Look, a tiny camera.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_screenshot@2x.webp?t=1772581464"> </figure> <p>It even got an even tinier viewfinder, which you can almost see if you zoom in 20×:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_screenshot_zoomed@2x.webp?t=1772581464"> </figure> <p>Or here. There is a box, inside that box is a circle, and inside it is a tiny letter <code>i</code> with a total height of 2 pixels:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_properties@2x.webp?t=1772581464"> </figure> <p>Don’t see it?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_properties_zoomed@2x.webp?t=1772581464"> </figure> <p>I don’t. But it’s there...</p> <p>And this is a window! It even has traffic lights! How adorable:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_window@2x.webp?t=1772581464"> </figure> <p>Remember: these are retina pixels, ¼ of a real pixel. Steve Jobs himself claimed they were invisible.</p> <blockquote> <p>It turns out there’s a magic number right around 300 pixels per inch, that when you hold something around to 10 to 12 inches away from your eyes, is the limit of the human retina to differentiate the pixels.</p> </blockquote> <p>And yet, Tahoe icons rely on you being able to see them.</p> <h1>Pixel grid</h1> <p>When you have so little space to work with, every pixel matters. You can make a good icon, but you have to choose your pixels very carefully.</p> <p>For Tahoe icons, Apple decided to use vector fonts instead of good old-fashioned bitmaps. It saves Apple resources—draw once, use everywhere. Any size, any display resolution, any font width.</p> <p>But there’re downsides: fonts are hard to position vertically, their size <a href="https://tonsky.me/blog/font-size/">doesn’t map directly to pixels</a>, stroke width doesn’t map 1-to-1 to pixel grid, etc. So, they work everywhere, but they also look blurry and mediocre everywhere:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/details_clean_up@2x.webp?t=1772581464"><figcaption>Tahoe icon (left) and its pixel-aligned version (right).</figcaption> </figure> <p>They certainly start to work better once you give them more pixels.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/ipad_comparison@2x.webp?t=1772581464"><figcaption>iPad OS 26 vs macOS 26</figcaption> </figure> <p>or make graphics simpler. But the combination of small details and tiny icon size is deadly. So, until Apple releases MacBooks with 380+ DPI, unfortunately, we still have to care about the pixel grid.</p> <h1>Confusing metaphors</h1> <p>Icons might serve another function: to help users understand the meaning of the command.</p> <p>For example, once you know the context (move window), these icons explain what’s going on faster than words:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/window@2x.webp?t=1772581464"> </figure> <p>But for this to work, the user must understand what’s drawn on the icon. It must be a familiar object with a clear translation to computer action (like Trash can → Delete), a widely used symbol, or an easy-to-understand diagram. HIG:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/hig_metaphor@2x.webp?t=1772581464"> </figure> <p>A rookie mistake would be to misrepresent the object. For example, this is how selection looks like:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_selection@2x.webp?t=1772581464"> </figure> <p>But its icon looks like this:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_select@2x.webp?t=1772581464"> </figure> <p>Honestly, I’ve been writing this essay for a week, and I still have zero ideas why it looks like that. There’s an object that looks like this, but it’s a text block in Freeform/Preview:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_text_block@2x.webp?t=1772581464"> </figure> <p>It’s called <code>character.textbox</code> in SF Symbols:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/character_textbox@2x.webp?t=1772581464"> </figure> <p>Why did it become a metaphor for “Select all”? My best guess is it’s a mistake.</p> <p>Another place uses text selection from iOS as a metaphor. On a Mac!</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_text_selection@2x.webp?t=1772581464"> </figure> <p>Some concepts have obvious or well-established metaphors. In that case, it’s a mistake not to use them. For example, bookmarks: <img src="https://tonsky.me/blog/tahoe-icons/bookmark.svg?t=1772581464">. Apple, for some reason, went with a book:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_bookmarks@2x.webp?t=1772581464"> </figure> <p>Sometimes you already have an interface element and can use it for an icon. However, try not to confuse your users. Dots in a rectangle look like password input, not permissions:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_permissions@2x.webp?t=1772581464"> </figure> <p>Icon here says “Check” but the action is “Uncheck”.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_mark_incomplete@2x.webp?t=1772581464"> </figure> <p>Terrible mistake: icon doesn’t help, it actively confuses the user.</p> <p>It’s also tempting to construct a two-level icon: an object and some sort of indicator. Like, a checkbox and a cross, meaning “Delete checkbox”:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_mark_unchecked@2x.webp?t=1772581464"> </figure> <p>Or a user and a checkmark, like “Check the user”:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_manage@2x.webp?t=1772581464"> </figure> <p>Unfortunately, constructs like this rarely work. Users don’t build sentences from building blocks you provide; they have no desire to solve these puzzles.</p> <p>Finding metaphors is hard. Nouns are easier than verbs, and menu items are mostly verbs. How does open look? Like an arrow pointing to the top right? Why?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_open@2x.webp?t=1772581464"> </figure> <p>I’m not saying there’s an obvious metaphor for “Open” Apple missed. There isn’t. But that’s the point: if you can’t find a good metaphor, using no icon is better than using a bad, confusing, or nonsensical icon.</p> <p>There’s a game I like to play to test the quality of the metaphor. Remove the labels and try to guess the meaning. Give it a try:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_guess@2x.webp?t=1772581464"> </figure> <p>It’s delusional to think that there’s a good icon for every action if you think hard enough. There isn’t. It’s a lost battle from the start. No amount of money or “management decisions” is going to change that. The problems are 100% self-inflicted.</p> <p>All this being said, I gotta give Apple credit where credit is due. When they are good at choosing metaphors, they are good:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_up_down@2x.webp?t=1772581464"> </figure> <h1>Symmetrical actions</h1> <p>A special case of a confusing metaphor is using different metaphors for actions that are direct opposites of one another. Like Undo/Redo, Open/Close, Left/Right.</p> <p>It’s good when their icons use the same metaphor:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/symmetry_import_export_right@2x.webp?t=1772581464"> </figure> <p>Because it saves you time and cognitive resources. Learn one, get another one for free.</p> <p>Because of that, it’s a mistake not to use common metaphors for related actions:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/symmetry_select@2x.webp?t=1772581464"> </figure> <p>Or here:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/symmetry_clipboard@2x.webp?t=1772581464"> </figure> <p>Another mistake is to create symmetry where there is none. “Back” and “See all”?</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/symmetry_app_store@2x.webp?t=1772581464"> </figure> <p>Some menus in Tahoe make both mistakes. E.g. lack of symmetry between Show/Hide and false symmetry between completed/subtasks:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/symmetry_eye@2x.webp?t=1772581464"> </figure> <p>Import not mirrored by Export but by Share:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/symmetry_import_export@2x.webp?t=1772581464"> </figure> <h1>Text in icons</h1> <p>HIG again:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/hig_text_icons@2x.webp?t=1772581464"> </figure> <p>Authors of HIG are arguing against including text as a part of an icon. So something like this:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/metaphor_select@2x.webp?t=1772581464"> </figure> <p>or this:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/similar_i@2x.webp?t=1772581464"> </figure> <p>would not fly in 1992.</p> <p>I agree, but Tahoe has more serious problems: icons consisting <em>only</em> of text. Like this:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/text_font@2x.webp?t=1772581464"> </figure> <p>It’s unclear where “metaphorical, abstract icon text that is not supposed to be read literally” ends and actual text starts. They use the same font, the same color, so how am I supposed to differentiate? Icons just get in a way: A...Complete? AaFont? What does it mean?</p> <p>I can maybe understand <img src="https://tonsky.me/blog/tahoe-icons/textformat_characters_dottedunderline.svg?t=1772581464"> and <img src="https://tonsky.me/blog/tahoe-icons/a_ellipsis.svg?t=1772581464">. Dots are supposed to represent something. I can imagine thinking that led to <img src="https://tonsky.me/blog/tahoe-icons/aa.svg?t=1772581464">. But <img src="https://tonsky.me/blog/tahoe-icons/textformat_characters.svg?t=1772581464">? No decorations. No effects. Just plain Abc. Really?</p> <h1>Text transformations</h1> <p>One might think that using icons to illustrate text transformations is a better idea.</p> <p>Like, you look at this:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/text_transformations@2x.webp?t=1772581464"> </figure> <p>or this:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/text_size@2x.webp?t=1772581464"> </figure> <p>or this:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/text_styles@2x.webp?t=1772581464"> </figure> <p>and just from the icon alone understand what will happen with the text. Icon <em>illustrates</em> the action.</p> <p>Also, BIU are well-established in word processing, so all upside?</p> <p morss_own_score="7.0" morss_score="9.0">Not exactly. The problem is the same—text icon looks like text, not icon. Plus, these icons are <em>excessive</em>. What’s the point of taking the first letter and repeating it? The word “Bold” already starts with a letter “B”, it reads just as easily, so why double it? Look at it again:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/text_styles@2x.webp?t=1772581464"> </figure> <p>It’s also repeated once more as a shortcut...</p> <p>There is a better way to design this menu:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/text_styles_inline@2x.webp?t=1772581464"> </figure> <p>And it was known to Apple for at least 33 years.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/hig_style@2x.webp?t=1772581464"> </figure> <h1>System elements in icons</h1> <p>Operating system, of course, uses some visual elements for its own purposes. Like window controls, resize handles, cursors, shortcuts, etc. It would be a mistake to use those in icons.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/hig_standard_elements@2x.webp?t=1772581464"> </figure> <p>Unfortunately, Apple fell into this trap, too. They reused arrows.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/text_arrow@2x.webp?t=1772581464"> </figure> <p>Key shortcuts:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/text_encoding@2x.webp?t=1772581464"> </figure> <p>HIG has an entire section on ellipsis specifically and how dangerous it is to use it anywhere else in the menu.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/hig_ellipsis@2x.webp?t=1772581464"> </figure> <p>And this exact problem is in Tahoe, too.</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/text_ellipsis@2x.webp?t=1772581464"> </figure> <h1>Icons break scanning</h1> <p>Without icons, you can just scan the menu from top to bottom, reading only the first letters. Because they all align:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/align_sequoia@2x.webp?t=1772581464"><figcaption>macOS Sequoia</figcaption> </figure> <p>In Tahoe, though, some menu items have icons, some don’t, and they are aligned differently:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/align_tahoe@2x.webp?t=1772581464"> </figure> <p morss_own_score="6.0" morss_score="8.0">Some items can have both checkmarks <em>and</em> icons, or have only one of them, or have neither, so we get situations like this:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/align_holes@2x.webp?t=1772581464"> </figure> <p>Ugh.</p> <h1>Special mention</h1> <p>This menu deserves its own category:</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/writing_direction@2x.webp?t=1772581464"> </figure> <p>Same icon for different actions. Missing the obvious metaphor. Somehow making the first one slightly smaller than the second and third. Congratulations! It got it all.</p> <h1>Is HIG still relevant?</h1> <p>I’ve been mentioning HIG a lot, and you might be wondering: is an interface manual from 1992 still relevant today? Haven’t computers changed so much that entirely new principles, designs, and idioms apply?</p> <p>Yes and no. Of course, advice on how to adapt your icons to black-and-white displays is obsolete. But the principles—as long as they are good principles—still apply, because they are based on how humans work, not how computers work.</p> <p>Humans don’t get a new release every year. Our memory doesn’t double. Our eyesight doesn’t become sharper. Attention works the same way it always has. Visual recognition, motor skills—all of this is exactly as it was in 1992.</p> <p>So yeah, until we get a direct chip-to-brain interface, HIG will stay relevant.</p> <h1>Conclusion</h1> <p>In my opinion, Apple took on an impossible task: to add an icon to every menu item. There are just not enough good metaphors to do something like that.</p> <p>But even if there were, the premise itself is questionable: if everything has an icon, it doesn’t mean users will find what they are looking for faster.</p> <p>And even if the premise was solid, I still wish I could say: they did the best they could, given the goal. But that’s not true either: they did a poor job consistently applying the metaphors and designing the icons themselves.</p> <p>I hope this article would be helpful in avoiding common mistakes in icon design, which Apple managed to collect all in one OS release. I love computers, I love interfaces, I love visual communication. It makes me sad seeing perfectly good knowledge already accessible 30 years ago being completely ignored or thrown away today.</p> <p>On the upside: it’s not that hard anymore to design better than Apple! Let’s drink to that. Happy New year!</p> <figure> <img src="https://tonsky.me/blog/tahoe-icons/smiley@2x.webp?t=1772581464"><figcaption>From SF Symbols: a smiley face calling somebody on the phone</figcaption> </figure> <h1>Notes</h1> <p>During review of this post I was made familiar with <a href="https://blog.jim-nielsen.com/2025/icons-in-menus/">Jim Nielsen’s article</a>, which hits a lot of the same points as I do. I take that as a sign there’s some common truth behind our reasoning.</p> <p>Also note: Safari → File menu got worse since 26.0. Used to have only 4 icons, now it’s 18!</p> <p>Thanks Kevin, Ryan, and Nicki for reading drafts of this post.</p> <h1>UPD: Notable mentions</h1> <p><span>January 5, 2026</span><span>·</span><span>Discuss on</span> <a href="https://news.ycombinator.com/item?id=46497712">Hacker News</a> <a href="https://www.reddit.com/r/apple/comments/1q4khhv/its_hard_to_justify_tahoe_icons/">Reddit</a> <a href="https://lobste.rs/s/2gvk2r/it_s_hard_justify_tahoe_icons">Lobsters</a></p> </article> <p>Hi!</p> <p>I’m Niki. Here I write about programming and UI design <a href="https://tonsky.me/subscribe/">Subscribe</a></p> <p>I consult on all things Clojure: web, backend, Datomic, DataScript, performance, etc. Check out my <a href="https://github.com/tonsky">Github</a> and get in touch <a href="mailto:niki@tonsky.me">niki@tonsky.me</a></p> </div> Mon, 05 Jan 2026 00:00:00 UTChttps://tonsky.me/blog/clj-simple-stats/ Announcing a simple statistics library for Clojure web servers <div class="page" morss_own_score="5.688984881209503" morss_score="10.620725495543974"> <article class="content" morss_own_score="9.863481228668942" morss_score="138.86348122866895"> <h1>Statistics made simple</h1> <p>I have a weird relationship with statistics: on one hand, I try not to look at it too often. Maybe once or twice a year. It’s because analytics is not actionable: what difference does it make if a thousand people saw my article or ten thousand?</p> <p>I mean, sure, you might try to guess people’s tastes and only write about what’s popular, but that will destroy your soul pretty quickly.</p> <p>On the other hand, I feel nervous when something is not accounted for, recorded, or saved for future reference. I might not need it now, but what if ten years later I change my mind?</p> <p>Seeing your readers also helps to know you are not writing into the void. So I really don’t need much, something very basic: the number of readers per day/per article, maybe, would be enough.</p> <p>Final piece of the puzzle: I self-host my web projects, and I use an old-fashioned web server instead of delegating that task to Nginx.</p> <p>Static sites are popular and for a good reason: they are fast, lightweight, and fulfil their function. I, on the other hand, might have an unfinished gestalt or two: I want to feel the full power of the computer when serving my web pages, to be able to do fun stuff that is beyond static pages. I need that freedom that comes with a full programming language at your disposal. I want to program my own web server (in Clojure, sorry everybody else).</p> <h1>Existing options</h1> <p>All this led me on a quest for a statistics solution that would uniquely fit my needs. Google Analytics was out: bloated, not privacy-friendly, terrible UX, Google is evil, etc.</p> <figure> <img src="https://tonsky.me/blog/clj-simple-stats/ga@2x.webp?t=1772581463"><figcaption>What is going on?</figcaption> </figure> <p>Some other JS solution might’ve been possible, but still questionable: SaaS? Paid? Will they be around in 10 years? Self-host? Are their cookies GDPR-compliant? How to count RSS feeds?</p> <p>Nginx has access logs, so I tried server-side statistics that feed off those (namely, Goatcounter). Easy to set up, but then I needed to create domains for them, manage accounts, monitor the process, and it wasn’t even performant enough on my server/request volume!</p> <h1>My solution</h1> <p>So I ended up building my own. You are welcome to join, if your constraints are similar to mine. This is how it looks:</p> <figure> <img src="https://tonsky.me/blog/clj-simple-stats/screenshot@2x.webp?t=1772581463"> </figure> <p>It’s pretty basic, but does a few things that were important to me.</p> <h2>Setup</h2> <p>Extremely easy to set up. And I mean it as a feature.</p> <p>Just add our middleware to your Ring stack and get everything automatically: collecting and reporting.</p> <pre><code>(def app (-&gt; routes ... (ring.middleware.params/wrap-params) (ring.middleware.cookies/wrap-cookies) ... (clj-simple-stats.core/wrap-stats))) ;; &lt;-- just add this</code></pre> <p>It’s zero setup in the best sense: nothing to configure, nothing to monitor, minimal dependency. It starts to work immediately and doesn’t ask anything from you, ever.</p> <p>See, you already have your web server, why not reuse all the setup you did for it anyway?</p> <h2>Request types</h2> <p>We distinguish between request types. In my case, I am only interested in live people, so I count them separately from RSS feed requests, favicon requests, redirects, wrong URLs, and bots. Bots are particularly active these days. Gotta get that AI training data from somewhere.</p> <p>RSS feeds are live people in a sense, so extra work was done to count them properly. Same reader requesting <code>feed.xml</code> 100 times in a day will only count as one request.</p> <p>Hosted RSS readers often report user count in User-Agent, like this:</p> <pre morss_own_score="7.0" morss_score="8.5"><code>Feedly/1.0 (+http://www.feedly.com/fetcher.html; 457 subscribers; like FeedFetcher-Google) Mozilla/5.0 (compatible; BazQux/2.4; +https://bazqux.com/fetcher; 6 subscribers) Feedbin feed-id:1373711 - 142 subscribers</code></pre> <p>My personal respect and thank you to everybody on this list. I see you.</p> <figure> <img src="https://tonsky.me/blog/clj-simple-stats/readers@2x.webp?t=1772581463"> </figure> <h2>Graphs</h2> <p>Visualization is important, and so is choosing the correct graph type. This is wrong:</p> <figure> <img src="https://tonsky.me/blog/clj-simple-stats/goat@2x.webp?t=1772581463"> </figure> <p>Continuous line suggests interpolation. It reads like between 1 visit at 5am and 11 visits at 6am there were points with 2, 3, 5, 9 visits in between. Maybe 5.5 visits even! That is not the case.</p> <p>This is how a semantically correct version of that graph should look:</p> <figure> <img src="https://tonsky.me/blog/clj-simple-stats/graph@2x.webp?t=1772581463"> </figure> <p>Some attention was also paid to having reasonable labels on axes. You won’t see something like 117, 234, 10875. We always choose round numbers appropriate to the scale: 100, 200, 500, 1K etc.</p> <p>Goes without saying that all graphs have the same vertical scale and syncrhonized horizontal scroll.</p> <h2>Insights</h2> <p>We don’t offer much (as I don’t need much), but you can narrow reports down by page, query, referrer, user agent, and any date slice.</p> <h2>Not implemented (yet)</h2> <p>It would be nice to have some insights into “What was this spike caused by?”</p> <p>Some basic breakdown by country would be nice. I do have IP addresses (for what they are worth), but I need a way to package GeoIP into some reasonable size (under 1 Mb, preferably; some loss of resolution is okay).</p> <p>Finally, one thing I am really interested in is “Who wrote about me?” I do have referrers, only question is how to separate signal from noise.</p> <p>Performance. DuckDB is a sport: it compresses data and runs column queries, so storing extra columns per row doesn’t affect query performance. Still, each dashboard hit is a query across the entire database, which at this moment (~3 years of data) sits around 600 MiB. I definitely need to look into building some pre-calculated aggregates.</p> <p>One day.</p> <h2>How to get</h2> <p>Head to <a href="https://github.com/tonsky/clj-simple-stats">github.com/tonsky/clj-simple-stats</a> and follow the instructions:</p> <figure> <a href="https://github.com/tonsky/clj-simple-stats"><img src="https://tonsky.me/blog/clj-simple-stats/banner@2x.webp?t=1772581463"></a> </figure> <p>Let me know what you think! Is it usable to you? What could be improved?</p> <p><span>December 15, 2025</span></p> </article> <p>Hi!</p> <p>I’m Niki. Here I write about programming and UI design <a href="https://tonsky.me/subscribe/">Subscribe</a></p> <p>I consult on all things Clojure: web, backend, Datomic, DataScript, performance, etc. Check out my <a href="https://github.com/tonsky">Github</a> and get in touch <a href="mailto:niki@tonsky.me">niki@tonsky.me</a></p> </div> Mon, 15 Dec 2025 00:00:00 UTChttps://tonsky.me/blog/hiring-ai/ A collection of red flags in software engineers' test assignments <div class="page" morss_own_score="4.880829015544041" morss_score="9.880829015544041"> <img src="https://tonsky.me/blog/hiring-ai/cover.webp?t=1772581463"> <article class="content" morss_own_score="10.0" morss_score="27.5"> <h1>How to get hired in 2025</h1> <p>It’s 2025 and you are applying for a software engineer position. They give you a test assignment. You complete it yourself, send it over, and get rejected. Why?</p> <p>Because it looked like AI.</p> <p>Unfortunately, it’s 2025, AI is spreading like glitter in a kindergarten, and it’s really easy to mistake hard human labor for soulless, uninspired machine slop.</p> <p morss_own_score="5.0" morss_score="9.0">Following are the main <em>red flags</em> in test assignments that should be <strong>avoided</strong>:</p> <ul> <li>The assignment was read and understood in full.</li> <li>All parts are implemented.</li> <li>Industry-standard tools and frameworks are used.</li> <li>The code is split into small, readable functions.</li> <li>Variables have descriptive names.</li> <li>Complex parts have comments.</li> <li>Errors are handled, error messages are easy to follow.</li> <li>Source files are organized reasonably.</li> <li>The web interface looks nice.</li> <li>There are tests.</li> </ul> <p>Avoid these AI giveaways and spread the word!</p> <p><span>November 26, 2025</span></p> </article> <p>Hi!</p> <p>I’m Niki. Here I write about programming and UI design <a href="https://tonsky.me/subscribe/">Subscribe</a></p> <p>I consult on all things Clojure: web, backend, Datomic, DataScript, performance, etc. Check out my <a href="https://github.com/tonsky">Github</a> and get in touch <a href="mailto:niki@tonsky.me">niki@tonsky.me</a></p> </div> Wed, 26 Nov 2025 00:00:00 UTC