A PageTemplate from Scratch

[pmario]

TLDR -- Executive Summary

If the PageTemplate designed for 1->4 doesn't work out for 5, there is still the possibility to switch the layout and have a desktop optimized template. ...

Nobody prevents us from using the existing one. But that's NOT what I want to talk about here. I want to talk about a completely new approach, that will use "the lessons learned" from the existing UI, but that's about it.

A Proposal for an Experiment

Since the Layout-Switcher exists, it's possible to change the PageTemplate on the "root level".

https://github.com/Jermolene/TiddlyWiki5/blob/856aca2f929ecef60ae8b8ab8c258b2a54702cb6/core/modules/startup/render.js#L24

The idea now is to create a "PageTemplate from Scratch", which should be Accessibiltiy-First, which will not be backwards compatible in any way. I want to get rid of all the bloat.

The guidelines should be

1. Accessibility First
2. Mobile First
3. Modern and Semantic HTML
4. Modern CSS
5. A Powerful Desktop App

add 1) Accessibility First

I am thinking about the idea presented at: https://heypresents.com/talks/be-the-browser-s-mentor-not-its-micromanager where the main credo is:

Be the browser’s mentor, not its micromanager

and

Everyone should get an excellent user experience

No one will ever complain about getting a good baseline experience

So the "readers experience" should be good. There should be "just enough" content on the main page, that the user gets started.

• Additional content is linked
• Full Table of Content can be reached at all times
• A minimalistic landing page should also give us good accessibility

2. Mobile First

I think if the initial content shown is minimal but "just right" it will not only help accessibility, it will also help mobile design. Most of the internet content is consumed by phones now. .. We shouldn't ignore this fact.

3. Modern and Semantic HTML Structure

There are a lot of HTML tags, that where designed to improve accessibility, but they are rarely used. They are well supported by modern browsers and accessibility tools. Some of them are used by TW already, but DIV is still the dominant HTML element on a TW page.

I'm talking about: NAV, ARTICLE, HEADER, FOOTER, ASIDE, SECTION and especially HEADING used in the right way.

• An example for a site that has the "reader" in mind can look like https://buildexcellentwebsit.es/, which is described at: https://heypresents.com/downloads/conference/2022/andy-bell.pdf at page 7

• I think a good example for an app-like HTML structue is the new MDN page . It contains

  • A header with always visible links
  • A navigation area just below the header
  • A left sidebar
  • A right "aside" local TOC
  • An always visible footer

4. Modern CSS

I think its necessary to re-think CSS and media-queries. IMO they are useless.

The reason is described at the youtube video: Andy Bell – Be the browser’s mentor, not its micromanager about different screen sizes available at 2015

IMO its simply impossible to get it right with media-queries. The approach in the video "may be" a possibility to solve "most" problems.

5. A Powerful Desktop App

While the Accessibility-First approach can lead to a good mobile experience and good accessibility, we still need an option for a "multi column, flexible, user-configurable" UI.

Conclusion

If the PageTemplate designed for 1->4 doesn't work out for 5, there is still the possibility to switch the layout and have a desktop optimized template. ...

Nobody prevents us from using the existing one. But that's NOT what I want to talk about here. I want to talk about a completely new approach, that will use "the lessons learned" from the existing UI, but that's about it.

Just some thoughts.

[joshuafontany]

This is well thought out and well presented. Will be following and hopefully have time to help once focus on this project at the new job ramps down.

[Jermolene]

Hi @pmario

The idea now is to create a "PageTemplate from Scratch", which should be Accessibiltiy-First, which will not be backwards compatible in any way. I want to get rid of all the bloat.

If we start with a new root template and apply your principles then we will be potentially replacing/changing every core template; given that every one of them is reachable from the root template.

I don't think that's a bad aim to have for the right point in the future, but we have to get there carefully.

In particular, at this point, prototyping more idiomatic and correct HTML is only one of a number of questions we need to consider:

• Do we stick with the same approach for managing the sidebar and other columns? The present arrangement is that the sidebar is absolutely positioned in the margin of the main page, but there are arguments for other approaches such as flexbox
• Do we want to change the functionality of the user interface itself?
• How can we make the components that comprise the user interface more reusable?

In the area of HTML usage, I think what would be most valuable at this point might be to put together a list of the specific problems that we want to fix.

If we are going to break backwards compatibility then there has to be a very profound benefit. In terms of layouts, I think the goal should be to improve the modularity and componentisation so that it is much easier to make custom layouts. #6666 will certainly help in that regard.

[pmario]

How can we make the components that comprise the user interface more reusable?

I think this is one of the most important questions. As I wrote I would like to have the possibility to seamlessly switch to edit mode. So we first need to find out the different elements that make up the UI at the moment.

The base mechanisms at hand are very flexible, but I think the elements of the sidebar should be more modular. Every element should do 1 thing well, if possible.

Then there is the tiddler info-area, which is very powerful and has been always there but it's heavily "under utilized". May be the top of the tiddler is wrong postion. It may be more visible and it may be better at the bottom of the tiddler, where we show, related links, node, notifications .... and so on.

[pmario]

the goal should be to improve the modularity and componentisation so that it is much easier to make custom layouts. #6666 will certainly help in that regard.

Exactly. I think using templates with parameters and the new related mechanisms can help a lot. .. That was also one reason, why I thought it should be created from scratch. It may be possible to create the UI elements we are used to with much "cleaner" wikitext. .. May be .. Experiments will tell ;)

[Jermolene]

Thank you @pmario those are all interesting suggestions, but the number of open questions makes it clear that at this point your work needs to be framed as an experiment; it's too early to frame it as a proposal for the core.

[pmario]

I did change the title to A Proposal for an Experiment. The whole thing is a discussion anyway.

[Jermolene]

Thanks – I should say that I agree entirely with your conclusions. We need a completely fresh start for all the core templates. The plan remains that after 5.3.0 we'll start to explore a roadmap to a v6 of TiddlyWiki that breaks backwards compatibility, with as many mitigations as we can manage to support older code. So we might end up putting all the existing templates into a backwards compatibility plugin, with the new templates using different naming conventions. I have even considered the possibility that this future version might use a different prefix for its native system tiddlers to make it really easy to distinguish older stuff from new stuff. (An example of the alternate system tiddler prefix might be $:// but perhaps we'd want to choose something that is the same length as the existing prefix).

[pmario]

I have even considered the possibility that this future version might use a different prefix for its native system tiddlers to make it really easy to distinguish older stuff from new stuff. (An example of the alternate system tiddler prefix might be $:// but perhaps we'd want to choose something that is the same length as the existing prefix).

That's interesting. For some time I was thinking about a possibility to get rid of the system-tiddlers from users view completely.

TW internally supports several wiki-stores. .. We already have "Shadow" tiddlers, which use a "protected" store area. We may be able to move all the system tiddlers into a "System" store, which is separated from the user store.

The main thinking is

• For new wikis the number of content tiddlers to shadow and system tiddlers is in no relation
  • may be 100 : 2260
• Even for tiddlywiki.com
  • it's 1479 (content) to 2260 (shadow)

For tiddlers with a lot of content the relation is in reverse eg: 40000 to 2260 ... Where every filter that is responsible to render the UI is influenced by the large number of content tiddlers.

IMO that wouldn't be the case, if the UI has it's own store. The time for rendering would be constant. Especially the caches for the UI could be kept alive much longer.

And since the UI system tiddlers would be out of view we wouldn't need to show them for default users at all. So we could still use $:/tags/Stylesheet for compatibility but $:/Stylesheet would become an option, since we would need to "switch" the store to see them.

From my point of view the only change needed would be to evaluate the bag-field. So system tiddlers can have any name. No prefix needed.

• if the title is: "-something" and bag is system it will be shown as: $-something
• if the title is: "$:/something" and the bag is system it will be shown as $$:/something

So the main rule for system-bag tiddlers is: They are prefixed with a $ ... That's all. As shown in my first example this may also lead to new naming conventions ... I personally would start all tiddler titles in the bag:system with a - or /, so the are shown as $-something or $/something

• If it is $:/something I know it an "old" sysetm tiddler with no bag field.
  • This should only be the case for old shadow tiddlers
  • If a user creates a tiddler that is prefixed with $:/ the bag:system will be created automagically
• If it is $$:/something I know it's an old system tiddler with bag:system ...
  • It's a user created system tiddler where bag:system is created automatically

just some thoughts

[Alzacon]

While the Accessibility-First approach can lead to a good mobile experience and good accessibility, we still need an option for a "multi column, flexible, user-configurable" UI.

IMHO, this point should be the first to think, before start working on it, the template. We need to define the basic structure and its parts, the content for each part, how customizable is each part. I know it because I have started a configurable template that has been continuously interrupted by doubts and problems of unnecesary complexity. Fortunely, I find hints and ideas, in the community, that I have can use them move forward*.

For example, we have to define where we can use "multicolumn":

• for story river part? As multiple story river.
• for sidebar part(s)? To add multiple sidebar.

Both could be solved with a (extra?) contariner, but... Do we want a "multicolumn" in sidebar part?



(*) Now I am working/stuck in the UI and logic of the layout configuration. The idea is a basic layout: A zone/container for story river, with a sidebar on each side, and horizontal bar (for menubar/toolbar). The idea of the configuration: diferent behaviour of the layout, and the main sidebar would positioned in right or left, the second sidebar is on the opposite side of main sidebar, the horizontal bar would be configurable between top and bottom position on mobile and desktop. I have thought about some limitation in the configuration of sizes of elements.

[pmario]

for sidebar part(s)? To add multiple sidebar.

There should be no difference between a sidebar and a story-river. It should be the same only its content should be different. At the moment there is a difference especially in HTML structure and therefore in the CSS too, which makes both of them more complicated as it should be.

[Alzacon]

I think I didn't explain well.

Yes, the container/zone/panel for story rivers and the other for sidebar(s) can have the same behaviour, they can have multiple content (stories/sidebar) in columns. But if we open a panel with several sidebars in columns, this have consequences for the rest of layout, mainly in the panel of stories if we have a fluid layout. Yes, we have sidebars inside of the our sidebar but they are (as tabs) in a extracontainer inside of sidebar panel. I am talking about sidebars as columns in the panel. So we need to define some restriction(s) for the sidebar panel(s) to avoid problems in the layout. Because I think we want a generic PageTemplate that serves the main uses of tiddlywiki.

[pmario]

[Idea]

the horizontal bar would be configurable between top and bottom position on mobile and desktop.

That's a good idea. I'll give it its own post ;)