when approaching UI design, I find it really helpful to layout the goals that the UI will need to support before doing any design.

So, here, I’d ask “what are the top few activities that someone would be looking to do when using this UI?”

inversely, I’d also ask “what actions don’t I need to support?”

that can help you decide what is a must have vs what is extra.

I guess the main activity would be looking for a certain piece of media someone has heard about. Maybe price isn't necessary then... :>

sort of following on that line “how will they be looking, what info do they need to find that thing?”

Hmm, yeah

Honest feedback, good start. Design is something that you just need to internalize, and look at lots and lots of other designs and see what speaks to you. Sometimes you don't know why a design looks so nice until you break it apart. Then you can use that information to build your own.

Contrast, size, alignment, proximity, shape, etc. all work together (or not). vwo.com/blog/crap-design-principles

There's also a book (maybe overpriced but still a great read) that gets more into the details:

practical-ui.com

A few other things to try is to put yourself in someone else's shoes. "I barely know how to use a mouse. What am I looking at, what should I do?". Another is using realistic, long text in designs. If you use short ones like "genre", you'll find later that nothing fits. One more thing is you can blur the design to get a feeling of weight and hierarchy. If you can generally understand the hierarchy (without clearly seeing the text or images), it's good.

What you have is so charming! I got noticeably cheerier after looking at it. Thanks for sharing. :)

I suspect putting real data in there might reveal a few small things to change, like I noticed that there’s probably not nearly enough room for artist and album names, for example.

If you want, worrydream.com/#!/MagicInk breaks down the user needs for a very similar store listing UI that I think is a good example of how you might answer many of the questions people are posing here like “What are people trying to accomplish?”

Oh yeah!! I was actually super inspired by Magic Ink, though I might not have a hang on the ideas

Thanks for those links @Mike Austin

I’ve found fnlfmt, for the fennel language really readable.

FYI, maybe - I’m not interested in speed, and this might not apply. I note that Ohm-JS has a interactive parsing mode (I haven’t tried it). I wonder if that means that one could attach semantics code (that’s the way that Ohm-JS is used) that does some formatting?

[reply from John] Again, thanks! I’ll definitely take a look. Most of the formatter parsers I’ve looked at (e.g. Prettier, Gofmt), will create the AST of the full file, create an IR, and then do the formatting.

I’m wondering if each of these steps can be streamed incrementally, and if you can do each operation in parallel.

My initial thought is, possibly, but not without some difficulties. For example, Prettier formats line breaks with some awareness of parent and subsequent sibling nodes in its IR).

This library implements a pretty expressive printer, following the algorithm presented in Porncharoenwase et al. ( 2023 ). The pretty printer is expressive, provably optimal, and practically efficient.

docs.racket-lang.org/pretty-expressive/index.html

Full paper here:

sorawee.github.io/pretty-expressive-oopsla23-artifact/full-paper.pdf

I know that CodeMirror uses Lezer, which is capable of doing incremental parsing. codemirror.net/examples/lang-package

If you're not familiar with CodeMirror, it's a text-editor component that is highly customizable.

tree-sitter is really fast, I don't know if anyone has built a formater for it?

Looks like yes! topiary is a thing

Again, thanks! I'll definitely take a look. Most of the formatter parsers I've looked at (e.g. Prettier, Gofmt), will create the AST of the full file, create an IR, and then do the formatting.

I'm wondering if each of these steps can be streamed incrementally, and if you can do each operation in parallel.

My initial thought is, possibly, but not without some difficulties. For example, Prettier formats line breaks with some awareness of parent and subsequent sibling nodes in its IR).

I realize it's a bit abstract. An example of "paged" tours wold be go.dev/tour/welcome/1

I've always loved this walkthrough: viewsourcecode.org/snaptoken/kilo

This looks like inline code (vs off to the side), and colored "diffs" to show the changes and also collapsed functions. I like it. Very visual.

Similar to what Kartik Agaram shared, I enjoy how Build your own Lisp is setup.

I particularly like that it makes evident a thought process behind the code. Many examples start with a naive implementation, and then, once the idea has been communicated the chapter concludes with a “cleaning up” section that gently optimizes what has been done before

Thank you Eli. Yes, it has a similar format and I like the build-ups. To support "visual diff" and code folding, I think I'll add Markdown code comments at the end of the line. Maybe something like:

NumericLiteral                  // >

  = value:[0-9]+ {

      return {

        type: 'NumericLiteral', // +

        value: Number(text())   // +

      };

    }

GitHub Markdown support adding + and - to the beginning of the line, but I want to be able to support other hints, maybe tooltips for example.

legit, I tend to shy away from tooltips because they are a headache to make accessible — I think that is why I’m drawn to this more literate code style, but I defo see the gap it leaves in getting comments sort of right as close to the code as possible

Maybe not hover tooltips, but like static popup notes

Assuming you already have good reference docs on your website, you might wait for the LLMs to crawl them and then create a tutorial chat UI on your site that asks the user for simple apps or examples they'd like to write, and walks them through how to do that.

Could also periodically have the LLM generate a bunch of simple examples with descriptions, for quick tutorial browsing. Conveniently, these would update as your docs and APIs do. It's possible the docs themselves could be autogenerated...

Ah yes, I haven't done much with AI/deep learning. That could be the start of my journey.