Clojurians Log v2

the way you get areas filled with parallell lines is really interesting.

Populating the larger grid with invisible grid-filling rectangles ripe for nesting with visible rectangles was easy and simple; for each grid field, I just pick random shapes (like 1x1, 1x2, 4x4 etc) from a preset collection and see if it fits, and continue to do so until every field is filled, or until I have to fill the remaining fields with 1x1 shapes 🙂 Just brute forcing it, really. Nesting the visible rectangles inside the larger invisible grid-filling rectangles also seems simple at the outset; just find the "center line" (in 1x1 and other squares, the "center dot") and lerp towards it from the outer corners (e.g., "go 1/10th of the distance from the top right corner to the center dot; this is the top right corner of the first nested rectangle. Then go another 1/10th - that's the top right corner of the second nested rectangle, and so on). There was a bit of fiddling to make it look right, though; if I recall correctly I had to smoosh some buffer in there at the outermost rectangles to make the outer lines of each grid-filling rectangle have the correct distance to lines of the adjoining grid-filling rectangles. And I think the buffer, in turn, affected the look of the lerped rectangles, so fiddle fiddle fiddle.

How do you do the drawing? Svg? Canvas?

AFAIK it draws to canvas, but I'm not interacting with it directly. I use p5js, the js version of Processing. Could have used quil (CLJ or CLJS flavored) or, for this, just drawn directly to canvas, since the operations are quite simple and I probably don't really need the niceties of p5js/quil. But it's what I'm used to 🙂

I had fun using quil a while back, but switched to p5js because I was in doubt about performance issues and thought I could get some more vanilla js in my bones than I do on my day job 🙂

And it makes me appreciate Clojure more 😄

> but switched to p5js because I was in doubt about performance issues I feel similarly — especially if I'm going to make something interactive. Making it run smooth enough to display without jank makes such a difference in how it's perceived …

To be honest, I didn't really investigate whether my performance issues were due to immutable data structures or something other Clojure-specific. Maybe the issues was just excessive data usage, immutable or not 😅

Yeah, it's hard to tell unless one measures properly!

It was while I was coming up with stuff like this

In all probability, there was a more efficient way to achieve the above. But I liked my dumb algorithm for its procedural "and then you do this, and then you do this"-paint-by-numbers-instructions-like quality, and it was mine 😄

fascinating, I like the waves and colors

similar things is being discussed around datastar now — when a certain piece of your infrastructure is really, really fast, you can afford simpler, stupider solutions other places.

Different examples:

I dug the waves, too, quite proud of how the pattern and the waves worked together. The palettes were not mine, at most I "curated" them lol, via https://coolors.co/

I've uses coolors too 😄 I like being able to "reroll into a starting point I like".

Yeah, it's quite good!

you still do a bit of creative selection, though, unless you put the first color combination you see in production without further thought 😄

we're currently doing something simlar on the front page of mikrobloggeriet (https://mikrobloggeriet.no/). colors are actually randomized, and filtered for decent contrast. Color functionality was written by @olav.moseng, sparring with a designer.

Arguably yes 😅 And you could say that the same thing happens when you select a palette without a tool like coolors, only slower and a bit differently. And, in my case, without any color theory to speed up or improve the process. One of my many "Yes I'd like to know more" items, very low on my list of priorities in life, is color theory, or constructing a palette by hand. As an "artist", I feel a bit of an impostor syndrome from being so limited in that regard.

Brave to go with complete randomization! The contrast thing works well. I guess it leaves it to the viewer to refresh until they find a scheme they like 😄 Interactive art 🤓

Yeah, that's quite cool 🙂 It's also a bit disorienting that it always looks different, and there's no way whatsoever to stabilize it 😄

Haha yeah. I was thinking that you could expose the colors via the URL and thus enable people to load the site with whatever palette they've come across and prefer, but it's not intuitive to use and (probably) not very easy to build.

yeah "add this weird ?colors=… to the URL" is something I wouldn't use myself 😄 I think a nice UI could be made for it, though. Reroll colors in one click, and save colors you like. I do miss the "save this combination" feature, sometimes a beautiful scheme loads, then the nest one actively hurts my eyes 😔

Yeah, using localstorage for state. Doable 🙂

server side might be easier in our case — the only js we currently have on the site is to enable filtering articles without page reloads, https://github.com/iterate/mikrobloggeriet/blob/f77450a86db3fa9523e251bf0a4b52e44eb35eda/public/js/filter.js

But yeah, doable!

Ah, I assumed it was a stateless kinda thing you had going

we've got state! Per now, two duratoms. One durable https://github.com/iterate/mikrobloggeriet/blob/f77450a86db3fa9523e251bf0a4b52e44eb35eda/src/mikrobloggeriet/cache.clj#L65-L71html cache>, one https://github.com/iterate/mikrobloggeriet/blob/f77450a86db3fa9523e251bf0a4b52e44eb35eda/src/mikrobloggeriet/analytics.clj#L20-L25.

but yeah, I see your point, that wouldn't have been possible with static html

Hm, how would you keep track of the user identity, though? Or would you have a global list of saved palettes?

probably require login through https://github.com/nextjournal/garden-id (we're running on application.garden)

A "pre-baked" list of good themes would be good, though.

Well, ability to save a theme without logging in could be nice. So maybe keeping something in client isn't a bad idea after all!

By the way, I didn't mean that the user should add the colours manually to the URL. Just add them to the address line of the browser via JS, and/or enable the user to save the link for the current theme by clicking a button and copying the URL, with the ?colors= added, into the clipboard or whatever. You could then "keep" your palette by having your bookmark for the site include the ?colors=. What I like about something like that is that it's stateless and shareable and transparent - the state is in your face, you can copy/paste it to give it to others, and you could even edit it manually, should you want. But it's probably frail, for example when copy/pasting links to the site that someone else sent, and suddenly your chosen palette is missing. And it's a bit more technical than what the average user is used to, so the UX probably generally isn't very good.