Idea: approach to palettes and themes

[Scott_Sauyet]

@Springer

I love this idea of a compact “thumbnail” for each palette!

I’ve been trying something and wondering if it’s worth pursuing. It’s a tiddler to show a thumbnail based on the current palette. Even in its incomplete stage, it shows the basic idea, and demonstrates some flaws, as in certain places the contrasts do not match the actual palettes. But it’s close, and with work could become much closer. Of course there’s much more content to add.

This shows it in action, a thumbnail that’s responding to a change of palette name from a dropdown:

(The pixelated backgrounds above are an artifact of my screen capture/convert to gif process. They’re not in the actual thumbnails.)

You can try it yourself by downloading this and dragging the resulting file onto any wiki:

Thumbnail.json (4.3 KB)

My thought would be to build enough to cover a fairly wide swath of TW output in the default layout. Obviously if we wanted more, we could show this with multiple distinct thumbnails, or combine them all into one. I was using this screenshot as my target:

So, first of all, does this look useful enough to be worth pursuing? It looks like a fair bit of work to get it as close as possible to a realistic palette demo. I haven’t decided myself whether it’s worth doing. Do others find this compelling?

Second, if it is worth pursuing, then I have a few questions for those who might have better understanding than I do about SVGs. Together they boil down to, “How can I optimize my process?”, but there are distinct questions:

• My text handling, in procedure line-text, was a reasonable first pass, but I don’t think it’s flexible enough. The heights are ok, and I mostly like the capital vs other heights, with a 3:2 ratio for those. But I use a shared parameter for character width and letter-spacing, and I don’t think this will scale well to different text situations. I think right now the text looks too heavy, but if I lower that parameter, the gaps look wrong. Is there any advice for how to handle this?

• I would love it if embedding SVGs from other tiddlers worked well. What I’ve done is to extract the SVG markup from those tiddlers, add heights, widths and positions, add dynamic colors, and add missing closing tags, all inline in my main SVG tiddler. Is there a way I can simply embed one SVG embedded in a tiddler inside another, controlling the size, position, and fill color without repeating the internal SVG source?

• Are there any suggestions for how to simulate bold or italic text with lines like these? Is it simply a skew transformation and wider rectangle, respectively? Or is there more?

• I’m looking around for nearest containing nodes that have a color assigned, finding that class in $:/themes/tiddlywiki/vanilla/base, and using the palette key from there, and sometimes starting from a rendered color and finding it in $:/palettes/Vanilla, trying to guess which key is the most appropriate choice. This is a tedious and error-prone process. Is there a better technique to find which palette key is in force in some rendered output?

[vilc]

This looks very impressive @Scott_Sauyet! I think it we’re going deeper in this idea, it might make sense to split the topic, because I think these are two quite different things:

• improving the presentation of palette when editing or choosing it – like Mario’s Palette Manager or your demo,
• improving the rules behind how the palette works and how to make creating/editing them easier – like the Captivate theme or my theorizing about the reduced number of “base” colors to edit.

Now back to your demo. It surely would be great to have this thing in a more complete form. However, I’m not sure if it is worth the effort needed. In the end, instead of imitating all elements of TW, we could just create a UI, like your selection box, to quickly flip though available palettes and view their appearance “live” in TW itself. I’m not sure if creating something that looks “almost like TW” just for palette preview is necessary. And it would probably become complicated with themes that go further away from Vanilla.

I thing the preview you have created can be useful if made less complex and smaller. If it used more symbolic elements for the sidebar/tiddler/text, it would be a great replacement for the “swatches of surprise” that we currently have in the palette settings.

I’m talking about a very simple symbolic preview like this one in Mattermost:

It would be incomparably better than

To sum up:

• simple symbolic preview as a replacement for the current “swatches” in the control panel, it doesn’t have to reflect all the colors, just the most important ones
• instead of creating an advanced preview it should be easier to create a UI to quickly change the current palette – if it’s needed at all
• this all just helps to present the palette, making it easier to edit or create is another topic

[Scott_Sauyet]

@vilc

I think it we’re going deeper in this idea, it might make sense to split the topic,

You may be right, and I have the ability to do that, but I’m going to wait a little while because I think of this tool a little differently than you suggest:

@vilc

I think these are two quite different things:

• improving the presentation of palette when editing or choosing it – like Mario’s Palette Manager or your demo,
• improving the rules behind how the palette works and how to make creating/editing them easier – like the Captivate theme or my theorizing about the reduced number of “base” colors to edit.

These clearly are two different ideas, but I think that a better editor would really help bring to life the simplified palettes and especially the creation of them.

@vilc

In the end, instead of imitating all elements of TW, we could just create a UI, like your selection box, to quickly flip though available palettes and view their appearance “live” in TW itself.

I think that’s fine for selecting palettes that have been created and tested. But when developing and testing them, we really don’t want someone stuck because they accidentally created an all-black palette. That’s how I was thinking of this. That it would also improve the palette selector is more of a happy accident.

@vilc

I thing the preview you have created can be useful if made less complex and smaller.

“Smaller” is a non-issue. This is created as an SVG; it will scale up and down as needed. “Less complex” is certainly a real concern. It’s the reason I paused here. There’s a lot to do, and it’s not clear to me how much benefit there is. I really like that Mattermost demo, but TW UIs are much more sophisticated than Mattermost, even in just the standard layout.

The detail I was going for was to try to capture as much of that sophistication as possible, but I think it would likely get overwhelming. In the site I mentioned above, the schemes could be shown pretty simply with just the swatches, but as @Springer pointed out, they are not enough to show things like text/background contrasts. I’m not sure what is an appropriate balance.

@vilc

simple symbolic preview as a replacement for the current “swatches” in the control panel, it doesn’t have to reflect all the colors, just the most important ones

And “just the most important ones” gets back to the origin of this thread. I don’t have time to respond now, but I’ll try to do so soon.

@vilc

instead of creating an advanced preview it should be easier to create a UI to quickly change the current palette – if it’s needed at all

Again, I think that is true for a palette-switcher, but not a palette-builder. The UI I had with a drop-down of palette names was just a tool to help me build/test the SVG. I would imagine that if used for a switcher, it would look much like Mattermost; if used for a builder, it would just be part of an automated preview.

@vilc

this all just helps to present the palette, making it easier to edit or create is another topic

I think it’s a nice ancillary tool in a builder. It does none of the logic, but offers immediate visual feedback as the user makes changes.

[Springer]

@Scott_Sauyet

It does none of the logic, but offers immediate visual feedback as the user makes changes.

You won’t be terribly surprised… but it turns out that the smallest things can make a preview seem to fail — even when it’s such a minimalist preview.

In particular, the swatch assumes that tiddler titles “display as links” setting is off, while the site title (for example) is not a link. Also, it looks for directly-named values, but doesn’t seem able to follow <<colour xxx>> referrals… The result is that the preview — even this simple one — can misrepresent where the contrasts are:

This tool would need to track when palettes refer some parts to other color-names (and doing so is a large part of what could make palette-building manageable!). Solar Flare, for example, doesn’t have its own site-title-foreground color, and instead points to <<colour tiddler-title-foreground>>… Neither that color nor the page background end up getting cashed out at their ultimate values in the preview:

I don’t envy the challenge of getting this kind of tool to behave, and understand if you’d turn to other things rather than obsess over getting this right!

Still, I do hope something like this is possible, and that someone will have not only the requisite css / svg chops, but also the patience to wade through the steps needed to iron out the kinks!

[Scott_Sauyet]

@Springer

You won’t be terribly surprised… but it turns out that the smallest things can make a preview seem to fail — even when it’s such a minimalist preview.

No, not surprised at all.

@Springer

In particular, the swatch assumes that tiddler titles “display as links” setting is off, while the site title (for example) is not a link.

We could easily add a small number of settings for things like this. The trouble is that as TW is infinitely customizable, there would always be things not covered. Again, this makes me wonder just how worth it this might be.

@Springer

Also, it looks for directly-named values, but doesn’t seem able to follow <<colour xxx>> referrals…

Oh, of course, that explains why things didn’t look right. When looking at a palette tiddler, I somehow assumed I was looking at source, and that the <<colour ... >> expansion would have happened by the time I used it. That I could definitely fix. It might even simplify the implementation slightly. (Or not, as I guess I don’t know what to do with missing colors, like button-background in Blanca.)

@Springer

Still, I do hope something like this is possible, and that someone will have not only the requisite css / svg chops, but also the patience to wade through the steps needed to iron out the kinks!

I think I can iron out some of the kinks, such as the color delegation. Handling other settings (title-links, for instance) is more of a challenge. If there are only a few, we could probably handle it, but we’d have to see how far we wanted to go, as there are far too many factors to account for.

I still am not sure whether this is worth pursuing, but if it is, I think the most important question is about the level of detail we’d want to cover. The screenshot I supplied above has an awful lot to implement…

[Springer]

@Scott_Sauyet

Handling other settings (title-links, for instance) is more of a challenge.

I’m actually more optimistic about this one: Any text “squiggle” (in sidebar or within tiddler-ish box) should simply render as a link sandwich: non-link foreground, tiddler-link (maybe with underline-style added, for iconic link-recognition purposes) then return to non-link foregroud. Of course, tiddler titles rarely appear mixed like that, but it’s easy enough to “get it” about how the regular foreground and link-foreground interact.

It’s true that external links can be an entirely different color, and none of this gets at hover effect colors (not to mention further tabs/tables/modals, etc.). But all that strikes me as getting a bit into the non-essentials (ideally, external links and hover variations on links are close in color to tiddler links, and differ only in something like a degree of hue, saturation, or value).

[Scott_Sauyet]

@Springer

@Scott_Sauyet

Handling other settings (title-links, for instance) is more of a challenge.

I’m actually more optimistic about this one:

My concern is about $:/config/Tiddlers/TitleLinks. Variables like this change how a TW is rendered, and if we wanted to cover that, we need a toggle for that value to use in showing the thumbnail. That wouldn’t be a big deal on its own. But how many others would we want to include? Each would need separate handling in the thumbnail generator. It could get unwieldy quickly.

[Springer]

@Scott_Sauyet

we need a toggle for that value to use in showing the thumbnail.

I don’t see why. Putting a link sandwich in each of the places where text can go is an easy way for people to recognize what color applies if/when they have a link in that <h2> tiddler-introducing position (which also can happen when caption is serving as header, even if “display title as link” setting is off), and also what the standard color is. Similarly for the title of the wiki, and for text within the dummy tiddler, and any text mockup within a tiddler subtitle area, etc… If it’s a link-sandwich, then people can see the normal foreground and the link foreground, even though they might rarely expect to use both.

[Scott_Sauyet]

@Springer

@Scott_Sauyet

we need a toggle for that value to use in showing the thumbnail.

I don’t see why. Putting a link sandwich in each of the places where text can go is an easy way for people to recognize what color applies if/when they have a link in that <h2> tiddler-introducing position

I can certainly try it, but I think it would just be distracting and lead to even more busy thumbnails. But I’m thinking that there are too many settings built in, never mind how it might be customized, to handle them all. One of my ideas was that this would be one of several views, and if that’s the case, perhaps the one that showed notifications and alerts could also show title links. But again, complexity always seems to grow. And that scares me.

[TW_Tones]

I have not read this whole topic and I appreciate you all looking into this. It’s true we could do more with a tiddlywiki aware preview. I just have a couple of points;

Don’t throw the baby out with the bath water. The color macros an perhaps some new ones are used within tiddlywiki and we could use these in even smarter ways.

• There a lot of color resources out there that help people select complementary an contrasting colors. A range of different color wheels for example.
• It would be nice if we could use macros either when setting a or modifying a pallet or even when changing one color. For example what if you could indicate the background color is the complement of the foreground color as represented in this color wheel?
• Or choose a few colors and have all the details change according to one of these color schemes.

Just food for thought.

[markkerrigan]

I have skimmed through the topic but I have still some thoughts from my recent palette development. There are a large number of tab and tab background colors all of which have a complex interplay, so it is not as simple as just choosing the background for the entire wiki, this is what makes it hard to map the colors to something like base16.

[Springer]

@TW_Tones

For example what if you could indicate the background color is the complement of the foreground color as represented in this color wheel?

This kind of thing — calculated transformations on existing colors — would be amazing.

It’s true that visual contrast does not neatly map onto mathematical contrast, and some “complementary” or visually contrasting colors are terrible against each other for reading contrast (green text on magenta background? No thanks, even without color-blindness!)… But it would be fantastic to go beyond allowing for exact palette value duplication (which many palettes take advantage of). It would be ideal to leverage css-based calculations to specify transformations of other palette colors.

For example, various link-related hover values could be based on their corresponding tiddler-link color, simply intensifying its contrast (dialing darker by 15% when the link is already displaying as a darkish color on a light palette, dialing up the brightness by 15% if the tiddler-link, before hovering, is a lighter color within a dark palette).

[vilc]

@Springer

This kind of thing — calculated transformations on existing colors — would be amazing.

I second that.

This is exactly what the Captivate theme is doing: calculating all colors from a palette of three base colors. And it works very well.
Now that I think of it, it does employ the model of a palette base (which it calls color scheme) and palette map (which it calls theme: light/dark/tan).

Taking this idea further, the “maps”/“themes” could be made easily accessible and editable, while remaining separate from the “palette base”. Captivate does all this behind the scenes, it takes the color scheme and theme as input, e.g. “blue sky” color scheme and “dark theme”, and creates a plain palette in current TW format.
So it shows that all the necessary color transformations can be done in TW.

[TW_Tones]

I did not think it easy but desirable. We need the relationships between elements to be known.

@Springer last time I looked into color wheels there are ones designed specificaly to give practical and pleasing colors based on color theory.

I realy think if we design a solution with another layer in it to base pallets on such curated color collections.

[Scott_Sauyet]

@Springer

This kind of thing — calculated transformations on existing colors — would be amazing.

There are plenty of tools out there in JS to lighten, darken, and blend colors. There are also plenty of color combination pickers; I’m sure we can build something useful if we choose. But it’s not so clear how much our existing themes would match something derivable this way based on a small collection of well-chosen colors. There are 135 named color keys in Vanilla!

@vilc

Taking this idea further, the “maps”/“themes” could be made easily accessible and editable, while remaining separate from the “palette base”. Captivate does all this behind the scenes, it takes the color scheme and theme as input, e.g. “blue sky” color scheme and “dark theme”, and creates a plain palette in current TW format.

This would be a useful place for TW6 to break backward compatibility, and move to such a model. Whether it’s Captivate’s three colors or four or five, or even six, it would be great to simply move in this direction. Trying to do it now in a backwardly compatible way is going to be tricky though.

[vilc]

@Scott_Sauyet

This would be a useful place for TW6 to break backward compatibility, and move to such a model. Whether it’s Captivate’s three colors or four or five, or even six, it would be great to simply move in this direction. Trying to do it now in a backwardly compatible way is going to be tricky though.

TW6 or a new theme. An idea of a new modern official theme plug in was discussed recently.

[Scott_Sauyet]

@Scott_Sauyet

I think I can iron out some of the kinks, such as the color delegation.

I was over-optimistic on this. I thought I could easily reproduce the handling of the <<colour>> macro on another palette. But I got stymied, and opened another topic to discuss it. It is seeming less and less likely that this is going to be as useful as I was hoping, though.

[Springer]

@Scott_Sauyet

There are 135 named color keys in Vanilla!

There are 88 with values actually specified (rather than being internally mapped onto other color-names), and about 58 once duplicates and redundant color words (green being green) are removed.

That’s still a high number! But the vast majority of them (in Vanilla) are shades of grey that vary quite predictably to mark differences like link-without-hover vs link-on-hover, or selected vs unselected tab background.

@Scott_Sauyet

There are plenty of tools out there in JS to lighten, darken, and blend colors.

Cool!

It would be amazing if we could leverage this power within TiddlyWiki, so that many of those minor variations could be handled by a macro like <<colour-darken primary 1>> (which might inch all hex values within <<colour primary>> toward black, by shrinking the R G and B hex-value-differences from 00 by 10% (or something like that for each of the rgb parts of the value).

If we could make a version of vanilla that specificies transformation-relations like this to track the “logic” of the vanilla template, that would be fantastic. Tweaks to just a few colors could then propagate through the whole palette. It would be worth doing an analogous thing for at least one simple dark palette as well.

[telmiger]

@Springer

@Scott_Sauyet

There are plenty of tools out there in JS to lighten, darken, and blend colors.

Cool!

One of them being ColorAction built/adapted some years ago for my own projects.

All the best,
Thomas

[Scott_Sauyet]

@telmiger

@Scott_Sauyet

There are plenty of tools out there in JS to lighten, darken, and blend colors.

One of them being ColorAction built/adapted some years ago for my own projects.

Very nice. This looks likely to be very useful!