Below is an example of an interactive widget I'm workshopping as a learning exercise & proof of concept.

clip-path: polygon(
    
);

Design Notes

This is more for my own future reference than for others to read it, so this is just a wall of text.

I hand-drew this page's design on paper before implementing it. Making it look like this has taught me more than if I made it look like other websites.

The most challenge for the smallest feature was the animated lines on the header of this page, my first JavaScript visual effect that randomizes & manipulates SVG.

The pagination through arrow panels on the left & right was initially inspired by my faint memory of the menu tabs on the left & right of the XBox 360 dashboard. I didn't spend much time with that interface, haven't seen it in years, and decided not to look at it while designing this page. This helped to keep the design as more of a product of my own mind, and the result is satisfyingly different from the original.

The color widget below is nice for me to demo some main color palettes, like lime on navy blue, pink on lavender, gold on burgundy, white on turquoise, they all capture different feelings & might even inspire new ideas on their own.

The borders on the color panel below and the tagline panel above, that also had to be done with SVG & JavaScript. I initially tried doing it with CSS border-image & its associated properties, but that caused the areas near the middle of the borders to be stretched undesirably unless I locked the size of the element. If I ever wanted to change the text content in one of these elements, I would have to change the border image again, which is a pain. So, I just wrote some fast-running JavaScript that generates a border image for each element that I want to have my custom type of border.

Other tests & widgets will be on the other panels. I'd thought about making the panels linkable the way React or Angular do with single-page applications, but to make the links visitable, my application would have to either leverage a backend redirect or generate pages that direct to this one before this page regenerates the url using a history replacestate. That's all fine for a frontend framework to do for a site that uses only that framework, but I don't want to be putting up a bunch of extra files for a potentially ephemeral feature on this homebrew page. I'm not sure I expect the content of these panels to be permanent in any way, so I'm not sure I should give them permanent links.

There's a tagline at the bottom, too. I'm not against AI, but it's... not very good for experimental visual design. Which, that's to be expected, it's a massive interpolator between large sets of data points that already exist. If visual design is samey in a lot of places, that's just the information it has to work with. That's not terribly helpful if you want a page that looks & acts like this one. Having AI in your toolbox is to be well-prepared, but as with any tool, a good toolman knows when to use it and when not to.

Quick Reference Links

Some review resources for refreshing or expanding my knowledge on Web technologies.

• MDN Web Docs
• W3 Schools
• My Personal Notes from a JavaScript Textbook I Read
• React Reference Overview
• Java Spring Official Guides
• Angular Official Documentation

Self-Reminder Note:

I have an issue with Java Spring repo layers that doesn't seem to have a solution built into Spring Boot. The use case was closed-source/trade secret, so I would need to re-create the problem in order to illustrate it in code. The issue is complex, so I'm writing it here to ensure I don't forget about it before I raise the issue with an illustrative use case in the Spring Boot repo on GitHub.

The issue is the attempt to use Spring Projections in tandem with Spring Specifications to create a dynamic self-constructable querying process that supports dynamic type outputs. Using Specifications in your repo layer requires the "findBy" method that takes the Specification of a given type, which can be a Projection. However, if you also want to use a Specification of a different Projection, one that has unlike joins or counting/grouping behaviors that are structurally unlike the original Projection, the "findBy" method in the repo will only be able to support one of them, not the number of them that you might want to support. In the Fluent API section of Specifications, it indicates that the findBy method takes a Specification<T>, and the problem is what that "T" is. It can be one Projection or the other; it cannot be both.