• Wednesday, 06/07/2023 ** 10:03 Settings panels - particularly for UI - are so difficult.

There are three real ways to drill down into them:

• Open a monolithic panel with form-like options. Navigate it like a document, with document tools that allow you to select parts and sub-parts of a page.
  • Pros: everything on one page, use the browser document tools, can write as much prose as you want about features
  • Cons: Discoverability is hard, documents are long and overwhelming
• Universal search. VSCode and Emacs take this approach, as do some MacOS tools and chrome feature flags. Type what you’re looking for and see the setting.
  • Pros: better discoverability
  • Cons: naming and language to describe features are hard
• Visual. Newer paradigm, mostly explored with browser modification tools like Arc’s. Visit the parts of the UI that you’d like to change and see how to change them on the UI itself. This can be a debugger overlay that feels similar to the dev tools; you could see a tray with a palette of options, selecting them to toggle them ‘on’ or ‘off’ on the screen. (This could be easily implemented for my website… whoah).
  • Pro: avoid language description whenever possible
  • Con: implementation is the most difficult, not possible for features that are strictly logical and don’t have a corresponding visual pane

This Google Calendar settings menu that I have open is wonderful; it’s document-style with a table of contents, and all of the settings have beautiful visual metaphors to help you understand how to navigate the page.

The Apple menu? Not so great, especially because they try to ‘own’ technical language and obscure actual features, like saying ‘pro display’ instead of 120hz or similar. This creates Apple tribalism and helps some die-hard fans feel more integrated - but choosing different names for products and settings from the colloquial standard basically alienates any casual user - which, IMO, is bad for a product like a MacBook that should be a tool usable by everyone. I don’t want to have to look up what an ‘epic pro max XDR ultra’ is - just use the language everyone else does. Please!

Major shoutout to the browser company shader this morning. When you first open the app, the full-screen blob and intro animation with music is so, so beautiful - maybe the best animation I’ve seen from software in a long time. That intro sequence is immaculate. I’m blown away by the work that these teams are doing on MacOS native apps. Developing those tools to be mac-native is feeling awfully tempting… wondering how easy it would be to port beautiful animated features like this back to Linux and wayland.

Using this Mac has helped me develop a new appreciation for my Linux setup though. All of the animations are beautiful and expressive on MacOS, sure, but my minimal Sway setup feels cold and efficient. Everything happens pretty much instantly without ‘affordances’ or motion blur or 120fps animations - it ‘just works’. The machine feels functional, efficient, and responsive. I would love to build more beautiful apps that feed into this ‘feel’ while taking some of the innovative visual cues from programs like MacOS. ** 10:16 Writing and recording these daily notes is probably - for better or worse - the highlight of my day. This is great practice. Keep noticing details and working on it! ** 11:10 Made another classic prioritization mistake today. Always make the minimum viable changes necessary to release a usable product for other people. I prioritized doing more ‘in-depth’ work before preparing a deployment of our product at work. Be more careful next time - propose a minimum viable plan, finish that plan, and iterate, adding more if we need. Do not do more up front than is necessary.