second take on a centered-fluid layout

[pmario]

This PR will modify the core "Centralised Theme" and add a new options in the ControlPanel : Appearance : Theme Tweaks

• Centered story, fluid sidebar
• Fluid story, fixed sidebar

You can play with it at: https://pmario.github.io/kitchensink/5800-centered-fluid-layout.html
(There is a little problem. If you change the theme, the Theme-Tweaks tab isn't updated. Needs some investigation)

If the option is selected, it will also "gray out" the metrics inputs, that are not active for this option.
It will also "gray out" unused options for "Fluid story, fixed sidebar"

These new options makes the Centralized theme much more flexible.

---

What's new

• Every "Theme Tweaks" setting has a "Back to default" button now, which should make it easy to undo experiments.
• The Centralised theme has less settings, which should make it easier.
• Unused settings have been "grayed out" which should make experimenting easier.
• The default value for Centralised "story width" is 800px
• The "width breakpoint" where it switches to "mobile mode" has been set to 1160px
• Snowwhite and Vanilla also got the "gray out" functionality.
• There is a minimum width now. So if you set storywidth to a very small value, you will still be able to see something
  • min is 500px

I needed to convert the settings into a theme, because the "Tight" and "Tight and Heavier" theme cause problems, since they hardcoded margins and paddings, which clashed with the centred setting.

[pmario]

@Jermolene What do you think?

[Jermolene]

Thanks @pmario. I'm not sure about extending the centralised theme. I made the centralised theme and the starlight themes very early on, more to demonstrate how to make themes than anything else.

I think now that the functionality of the centralised theme should be built into the vanilla theme as a setting, at which point the centralised theme plugin would just consist of a configuration tiddler enabling that setting.

With this PR, the duplication of the Vanilla ThemeTweaks page seems unfortunate. There are other situations where we have obscure near-duplicates of core tiddlers, and it's very hard to keep them up to date with one another.

I understand the motivation for disabling settings that don't apply, but it seems a lot of complexity for only a small benefit – disabling input controls actually often confuses users because they can't always understand why they are not working.

I also note that you use # as a way to include comments in tiddler dictionaries. I don't think that is a technique that we want to encourage because it has obvious pitfalls.

[pmario]

I think now that the functionality of the centralised theme should be built into the vanilla theme as a setting, at which point the centralised theme plugin would just consist of a configuration tiddler enabling that setting.

I initially did have the centralized setting be part of the vanilla theme. ... The problem is that "centralized", "Tight" and "Tight and Heavier" contain hardcoded changes that completely clash with the "Theme tweak" settings.

[pmario]

I understand the motivation for disabling settings that don't apply, but it seems a lot of complexity for only a small benefit – disabling input controls actually often confuses users because they can't always understand why they are not working.

I think the contrary is the case, if we add tooltips. ATM users can change the settings even if it isn't useful and doesn't work. They mess up the settings and completely leave the project and tell everyone that they will loose data if they use TiddlyWiki.

See:

from Hacker News
Tried Tiddlywiki based on recommendations on this page. Started nice and saved few pages, could update the settings etc. Then updated the setting to widen the wiki column size and suddenly all the links (like Home/Settings etc) stopped working with exception of Theme/Appearance and Save. Thankfully didn't put a lot of content in it. I guess I'll have to continue with dokuwiki + my plaintext markdown note setup.

The setting he mentioned is easy (for me) to replicate but extremely hard to diagnose for others. To replicate it.

• Go to tiddlywiki.com
• Activate the "Tools : Themes" button in the sidebar
• Go to ControlPanel : Appearence : Theme Tweaks
• Set: Story Width -> 830px
• Try to click the "config" or the "+" button .. They don't work
• Try to click the "theme" or the "save" button. .. They do work

As you can see it's super easy to mess up the settings and nobody helps new users with those settings that are completely confusing on their own. ... These settings "just don't work" for newbie users!

My desire is to fix it and disable settings that are not valid. ...

I personally don't like "hidden settings" because if a setting is hidden and a new user visits the page, they don't see the setting. So they will never know that a setting, they may need in the future, even exist. ... On the other hand, if they see a disabled but visible setting they start to ask: What does it mean? Why is it disabled? ... IMO that's a 100 times more useful as a setting, they have never seen.

To make "disabled params" more self-explaining, it will be possible to add a "disabled ... because layout is : xxxxxx" tooltip.

[pmario]

As I wrote, I would be willing to fix the problems I see,

• I would need to change "Centralized" in the way you described.

• I would need to change "Tight", "Tight and Heavier" themes and add "Theme specific" parameters to the settings table.

• Every theme parameter would get a "Set back to default value" button. Partially included in this PR

• Every theme would disable parameters that can't be changed because the theme "hardcodes them" or "blocks" them. So users don't mess with settings that "just don't work" with the actual theme

[pmario]

I also note that you use # as a way to include comments in tiddler dictionaries. I don't think that is a technique that we want to encourage because it has obvious pitfalls.

This possibility has been there since 9 years https://github.com/Jermolene/TiddlyWiki5/blob/master/boot/boot.js#L376
It was introduced with the commit: 5c9b0d6

I use it all the times. IMO good inline comments save 100 lines of extra docs for config tiddlers.

[pmario]

I personally don't like "hidden settings" because if a setting is hidden and a new user visits the page, they don't see the setting. ..

From my point of view, how damaging for TiddlyWiki "hidden content" is, is best shown by the success of Dave Giffords projects. He did put "Backlinks" out of the tiddler info-area into the ViewTemplate. ... The reaction of the community should tell us everything. Nobody seemed to know, that this info has always been there, because we did hide it.

[Jermolene]

I think the contrary is the case, if we add tooltips.

We can't rely on tooltips because they are not supported on touch devices.

ATM users can change the settings even if it isn't useful and doesn't work. They mess up the settings and completely leave the project and tell everyone that they will loose data if they use TiddlyWiki.

That's definitely a problem that we should fix, I'm just arguing that disabling these settings isn't the best way to do so.

As you can see it's super easy to mess up the settings and nobody helps new users with those settings that are completely confusing on their own. ... These settings "just don't work" for newbie users!

My desire is to fix it and disable settings that are not valid. ...

I personally don't like "hidden settings" because if a setting is hidden and a new user visits the page, they don't see the setting. So they will never know that a setting, they may need in the future, even exist. ... On the other hand, if they see a disabled but visible setting they start to ask: What does it mean? Why is it disabled? ... IMO that's a 100 times more useful as a setting, they have never seen.

I've no problem with improvements to Snow White/Vanilla, but I think the best way to approach this is via #4473, which you can see me experimenting with at https://twpub-tools.org/

To make "disabled params" more self-explaining, it will be possible to add a "disabled ... because layout is : xxxxxx" tooltip.

As I say, we can't rely on tooltips, but even where they do work, there is little evidence that users actually read tooltips.

[pmario]

May be "sidebar resizer" will fix the problem as a side-effect. Users should not need to mess with the hardcoded values. "Hope dies last"