If a page with page decorations enabled is reached and you follow to any page referenced from the page then the page you reach will inherit the page decorations of the referencing page if there are no page decorations already present. This would be toggleable with some page decorations knob (e.g., inherit: true).
This allows to extend UX while browsing through the space and allows to reach the very same page through several paths having different page decorations for each of the paths. What do you think about this idea?
Let me know if I understand correctly. Suppose you have three pages:
Decorated with inherit
Page A
Page B
So if I click on [[Page B]] on [[Decorated]], I will see Page B with decoration. But when I click [[Page B]] on Page A, I will open Page B without decoration?
If that’s the idea it’s not obvious what I’d use it for
While on [[Decorated]] simply clicking [[Anything]] there will cause the [[Anything]] inherit the decorations of the [[Decorated]]. But not only that! Once you are on [[Anything]] and you click [[Somewhere else]] there then also the [[Somewhere else]] will still inherit the same starting decoration of the [[Decorated]]. And so on, unless you reach some page already having some decoration declared (with or without the inheritance directive in place).
At that point, if there is already a decoration while we are already “browsing” our space with some inherited one, we could either merge the two (which may be awkward) or simply override the current decoration (prefered for simplicity). But if decoration on a page is declared with the inheritance directive in place, then it will override the original inherited one and when leaving that page, it’s decoration will be inherited instead of the original one.
(Uff, that should rather be described in terms of a program flow rather than by words.)
Use case can be, e.g., to visually “detect” that you are crossing boundaries of some information clusters formed by (cross-)references etc.
In fact, that would be better done at data level but it will require true graph database to be involved. There are the “trees” (DAGs) of pages but references between them form graphs (directed and cyclic). I just tried to come up with something that would not require the graph database involved by shifting the problem to the UX level only workarround. Maybe it really does not make much sense…
I can imagine that if I divide my space into a tree of “green” pages and “blue” pages, which stay their colour regardless of the path you reach them with. Then if I visit any “colourless” pages, then they would keep the colour of the coloured page I visited it from…
Still, I think I’d just keep the colourless pages without the decoration, and just be wary of seeing any blue, when I want to be browsing green/colourless.
I think the graph of connections between pages is reasonably accessible when authoring a Plug, maybe you could do something fun with that
Now pages are stateless, meaning that visiting a specific URL (uniform resource locator) always gives you the same page (resource). I think it’s a very elegant solution to WWW in general and maps into Silverbullet nicely.
I didn’t really care about Page Decorations that much, but after reading this I’m going to colour my tags right now, thanks!
