• Saturday, 05/27/2023 ** 13:19 Tried watching some "Tsoding" streams to see what steaming for programming looks like. I'm not sure if I'll start streaming again, but his investigation of Zig was very insightful.

Almost-quote of a language: "Developing a language could be just like discovering a game. A game is designed to teach you how to play it - to discover new tips and tricks without realizing that the system is teaching you how to progress. The process of using a language - from the starting process, the error messages, and so on - should be designed like a game, to inform the user to navigate the language and teach them features."

All computer programs are the same; a program is a tool that a user has to learn. Choosing the right way to help your users is vital to helping your users understand how to use your program.

Do I provide a manpage? A --help flag? Good error messages? A website with a great search bar? An interactive tutorial? A supportive Discord community? How do I determine what the best way is to teach my users to use my software?

Today I've also been testing out the Helix editor, software that claims to be a modern replacement from neovim. The program claims to be a complete rewrite, but effectively rewrites and compiles in expressive neovim packages and configurations to produce the best source code editing experience out of the box. The best aspecf of this is the help menu, though - as soon as I started typing and saw a keybind that I didn't expect, I was (1) shown a menu of all possible keyboard shortcuts, and (2) shown an English explanation of my action in a pop-up. I felt encouraged to play - trying more keyboard shortcuts helped me understand more about the system! - and it was incredibly easy to find tools like the file browser and to start using the modal editing features. It's still a bit confusing to open the program to an empty buffer - but their onboarding experience is doing a lot of things right.

At work, a principle design focus is killing any sort of product tour. We include one as a crutch - it allows us to explain features we're quickly adding support for to the platform because we're building a product without clear competitors or comparators - but making UX feel seamless - teaching the user to use the product as they explore - is our primary focus. Presenting information-dense views with affordances to attract the eyes to particular aspects of the interface encourages the user to look at - and interact with - parts of the screen, and in doing so, I hope they learn. ** 13:40 Test for my website's sidebar hierarchy:

home ├╴pages ├╴c ├╴c-style ├╴ helpers ├╴making-c ├╴journals ├╴2020-10-10 ├╴2020-10-05 ├╴files

and questions:

• How do I better visualize deep nesting? (The above isn't very clear.).
• How deep should a website go?
• What should be visualized? Connections? Graphs? Headings? What is important enough to visualize?

Some pros:

• I love the table style that I have going so far, and think it will apply wonderfully to ascii art. It's a wonderful pattern to reuse.
• The website should feel as configurable and as interconnected as possible; things changing on one page should affect others, information should be shared whenever possible.

Thoughts on the framework so far:

• I am loving zig's 'comptime' features. I can feel the paradigm in my website framework too. The framework has three distinct stages: the static generation stage, the javascript integration stage, and the deployment to user stage. Each has different information available, and our goals are to both minimize the amount of work necessary to redo that information and to make use of that information in a way that's as expressive as possible. There are still lots of things to solve, i.e.: How does hot reloading function for pages depending on source files? What information do we want to show on the site that's "live" (loaded when the client visits the website - as opposed to loading the information when the file is built or when the file is served). ** 13:56 I want a git commit that tracks not only when it was made, but also where it was made, how the weather was, etc... ** 20:10 Taste is changing. I used to think that keeping photos flat, collapsed, straightforward, with lines pinned and corners all at sharp angles, was the way to go. The more work I do and the more time I spend outside, the more I realize that I want my screen to feel expansive and broad, to include as much information as possible, to make the viewer feel a real sense of depth - like they're not just squaring up with a digital screen, but that they're seeing another place.