Improve page layout #4473
Comments
|
@Jermolene I hope this PR could address also the odd behavior of those story views. |
|
The https://codepen.io/jermolene/pen/mdJBqGz resembles the single page layout which is quite useful to create website using Tiddlywiki. |
|
@Jermolene Look at the very tiny scrollbar under description. One more thing is: The TW page layout shall adjust itself fluently to mobile/tablet/desktop/widescreen size devices. |
|
Hi @kookma
The issues you've run into are largely due to the way that the current page layout requires the story river to be sized explicitly, rather than just filling its container.
If the DOM representation of a tiddler in full screen mode required deletion and recreation as part of the refresh cycle then it would pop out of full screen mode. So, as I think we've discussed elsewhere, it's better to put the entire window into full screen mode, and use the new solo with the sidebars/toolbars hidden by CSS.
The problem isn't that there two scrollbars, it's that the positioning of them is currently wrong. |
|
I've updated the original post with some notes about CSS grid. |
|
@Jermolene Thank you again! |
True!
That is right! I hope we could have solo final release soon. |
|
I'm very much in favour of a css overhaul. Suggestion: Make a Holy Grail layout as default but with left sidebar and footer inactive/empty. Or, considering that...
...maybe there could be multiple page templates? Might this simplify designing futher Story Views? Somewhat off-topic: I hope a Stylesheet overhaul will take the opportunity to chunk up the stylesheet monoliths into tiddlers. |
|
Folks, I applaud your work on this but would ask if you can consider the following
Regards |
We will probably make the page template switchable, but I'm not sure what else you're thinking of here.
That would be theoretically possible but I'd be very concerned that it would introduce inconsistencies that would make support and subsequent development much more difficult.
I think it would be much easier to do that as an illustration, it would be very complicated to try to integrate those labels into the layout without disrupting it.
Again, you'd have to explain this a little more. To explain things another way, the current layout you see on the prerelease is the result of overlaying three independent components: the story river, the sidebar, and the new menu bar. Their layout is entirely independent: we just arrange margins and padding to try to stop them blotting each other out. That's the fundamental problem with the current layout that we keep running into: whenever we change the layout of one of those three page components we have to meticulously adjust the layout of the others. That's what changes with the proposed new layout: it's entirely fluid, with the page components flowing to take up the available space. Flexbox gives us a lot of flexibility for how those components react to the screen size changing too. |
This is great! while I am note sure flexbox or modern grid option, BUT I propose the page should have all essential element even if all of them are not used in the current release. I mean this layout
This way one can customize the design and choose UI elements and create a blog, a website or a wiki or a noteApp, ... What is proposed now has only top and right bar and a story river |
|
I'd like to have several story rivers. 3 or 4 make a nice fit for ultra-wide screens |
|
Hi @twMat @kookma @pmario I'm not doing a good job of explaining things! The whole point of this layout is that one can just drop in additional toolbars, story rivers and sidebars and the layout just adapts automatically. You can experiment directly in CodePen, but perhaps I should add some JS buttons to make things a bit more obvious. Also, the "holy grail layout" is not really any help because in it's classic form the page scrolls as a whole, they don't usually have our approach of separately scrolling the sidebar(s)/river(s). |
|
Question: does it mean no left sidebar/footer(bottom bar) will be available in new page layout? Or it means, these can be done by intermediate users. I love the current right sidebar and fluid storyriver, but in some applications like software tutorial e.g
one likes to have left sidebar and a footer. Or when a website is made using TW. Similar solution by JD But these are not straight forward to customize and they overwrite several core tiddlers. |
|
Hi @kookma
No, I just mean that the various "holy grail layouts" that you find on the web are not actually suitable for TiddlyWiki because they scroll the page, rather than independently scrolling the story river and sidebar as we do.
Yes, the layout proposed here supports arrangements like a left sidebar and a footer. |
|
I've updated the CodePen with buttons to create/delete page components.
|
|
In case you want to experiment without the CodePen paraphernalia, here's a plain HTML version. |
|
@Jermolene |
|
I did some experiments. It is really cool! I love the immobilize header/footer/sidebar. I intentionally do not use sticky! |
|
Sorry, I am a jhonny come lately, I tried to express this in a GG thread. The layout example is great, and two stories has much potential, if same or different. I found a layout for printed pages which provides an even more comprehensive set of locations If the rows and columns are defined correctly the page responds when content is present only. With such a layout I doubt there would be any missing positions. To help even further these can be used when printing as well using the media styles etc...
|
I played a bit more with this layout and found on small screen the footer is better to stick at the bottom of story river so I may suggest: I think the next ingredient is to see how layout is responsive on different screen size! |
|
Hi @AnthonyMuscio I'm not sure what you're proposing; that illustration appears to be a naming scheme for areas of a page margin, I'm not sure why that is relevant? |
|
Hi @kookma I'm glad you're enjoying it!
Sticky footers are actually quite hard to use on iPhones because touching the bottom of the screen usually causes the browser toolbar to appear, which shifts the footer up the screen.
Yes indeed. With this layout we'll be able to selectively hide the sidebar for small screens and have everything else flow to take up the space. |
|
This layout is very fun to play with, thanks @Jermolene for the pen and the mockup html 😄 What I'm wondering is if navigation needs a big overhaul? I tried to apply the styles to an empty tiddlywiki with an edited pagetemplate and noticed that navigation didn't work anymore |
|
I thought it's probably the pagescroller that needs to get the correct scrolling element |
|
Hi @BurningTreeC that's correct, rather than using CSS |
|
Nice to read that there's a plan @Jermolene 👍 |
|
Jeremy
A brief response. If you look at the diagram I shared you will see that there is a way to address left right and center both in the margins and above the main page element also left and right. I imagin the main page to be the story river. We already can address many of these locations even with a tag. My idea is to pre provision each of these positions as an addressable location along with above and below story. If the three footer elements below the page were used then the story in the center could be scrollable within the central space.
In your first example i was impressed by the possibility of two stories. Not sure how that would work here.
However i have seen flexible layouts where unless one of these positions is addressed it may as well not be there. So if i filled the top center only with menus it would expand to fill the whole row.
If none of the left columns were used there would be no left sidebar.
I also imagin the center left right top and bottom set to remaining visible and in position when you move scroll. Is that float? The existing sidebar would be in the right centre. With nothing above it.
I know i am a little imprecise and dont know the correct terms i just like the idea of ensuring each of these positions could be given content.
With a comprehensive set of areas i find it hard to imagine a layout we cant use.
I used an advanced word press theme once like this.
Regards
Tony
Get Outlook for Android<https://aka.ms/ghei36>
…________________________________
From: Jeremy Ruston <notifications@github.com>
Sent: Friday, March 13, 2020 8:44:47 PM
To: Jermolene/TiddlyWiki5 <TiddlyWiki5@noreply.github.com>
Cc: Anthony Muscio <anthony.muscio@PSaT.com.au>; Mention <mention@noreply.github.com>
Subject: Re: [Jermolene/TiddlyWiki5] Improve page layout (#4473)
Hi @AnthonyMuscio<https://github.com/AnthonyMuscio> I'm not sure what you're proposing; that illustration appears to be a naming scheme for areas of a page margin, I'm not sure why that is relevant?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#4473 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHQ7DEWCPD23FREZTPNBRK3RHH6A7ANCNFSM4LC36EWA>.
|
|
Hi @AnthonyMuscio I'd really like to understand what you're proposing. Perhaps some sketches would help? The way that the layout proposed here works is that first the screen is divided into horizontal strips, one for the toolbar and one for the story river and sidebars. The so-called "main" strip is automatically resized to fit all of the strips onto the screen at once. Then the main strip is further divided into vertical strips: the difference between a sidebar and a story river is that the sidebars have fixed width and the story river(s) expand to fill the available space. Applying all of this to TiddlyWiki, there would be new system tags for adding horizontal strips, and for adding vertical strips within the main strip. Some of the strips would themselves be composed from system tags -- for example, the menu bar is composed from system tags identifying menu items. |
|
This is really cool. Now that you have described the layout system, it
totally seems possible to provide tags for Tony's use-case. A tag to
position a div in the header/footer bars that are floated/aligned and sized
to match the left or right sidebar would get most of the way there. You
would have to watch the vertical size of the content there, as these are
'hosted' in the header/footer bars and anything taller than your other
header/footer elements would start to "blow out" the layout.
Seriously exciting, great work!
…On Fri, Mar 13, 2020, 5:07 AM Jeremy Ruston ***@***.***> wrote:
Hi @AnthonyMuscio <https://github.com/AnthonyMuscio> I'd really like to
understand what you're proposing. Perhaps some sketches would help?
The way that the layout proposed here works is that first the screen is
divided into horizontal strips, one for the toolbar and one for the story
river and sidebars. The so-called "main" strip is automatically resized to
fit all of the strips onto the screen at once.
Then the main strip is further divided into vertical strips: the
difference between a sidebar and a story river is that the sidebars have
fixed width and the story river(s) expand to fill the available space.
Applying all of this to TiddlyWiki, there would be new system tags for
adding horizontal strips, and for adding vertical strips within the main
strip. Some of the strips would themselves be composed from system tags --
for example, the menu bar is composed from system tags identifying menu
items.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4473 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACFOMB2LBYNDKP5ILUUDVTLRHIOZHANCNFSM4LC36EWA>
.
|
|
Jeremy,
The image I shared earlier was as much of a sketch I can think of giving you. I think the essence of my argument is not being happy with a simple bar header/footer, but pre-provisioning all the elements in the page in the image I gave, whether they are used or not. But dividing both headers and footers and left and right sidebar into 5 elements perhaps with the central element by default fixed on scrolling it is possible to reproduce the current tiddlywiki layout. Each of these elements could be given default css so they are practical to use, such as top and bottom centres being centred, left and right inner and corners text aligned right, the left and right centre items fixed on scrolling etc... I imagine a config panel tab with this layout diagram where one could click to activate each element. and set its width or hight (or leave it to respond to the content). The ultimate would be if you could choose additional rows or columns, for example two header rows, the top using left and right elements and logo in the centre one, then a second header row using only the centre element containing the site name or main menu. Two columns on the left would be a double side bar one of which appears on hover etc... The diagram is comprehensive but we could add above story and below story as elements and the top and bottom of the story river(s). Have I made this any clearer for you Jeremy? Thanks for your patience. I am inspired by what you have already shared. |
|
PS, If multiple stories are available I can imagine being able to have a fixed or scrollable left / centre / right element at the top/bottom of each story "window". |
|
Hi @AnthonyMuscio I don't see a way to square your suggestion with the way that the layout proposed here works. As discussed above, it uses flexbox to divide the window into horizontal slices, the main one of which is also divided into vertical strips. That's fundamentally different than your diagram, and provides much more flexibility. Note that there's nothing to stop one subdividing the slices/strips further into the 5 chunks you propose, again one would use flexbox for this. |
|
scanningg through the above and trying to grock 'wtf is flexbox' i found this (Full-Screen Layout using Flexbox) |
|
Jeremy,
Your codepen example is great, I am just asking if we can take the headers and sidebars a little further to pre-provision "all possible" page design elements. I am not dictating the method. I am suggesting doing this five element model vertically and horizontally even if is an alternate configuration. The idea is to make the whole thing responsive as I expect flex box would. In effect I am proposing to pre-provision the elements just as we use above story etc... which are hidden unless they contain content. If designed well one could use the centre header element and set it to 100% to match your code pen example The idea is the element will not be displayed if it has no content. By simply choosing which elements have content will describe the wikis overall layout. This model is comprehensive and would also lend itself to responding to mobile screens and if choosing to print the window. The centre horizontal and centre vertical would move with the scroll of the story, if you want a fixed sidebar you use the fixed element, I would be tempted to add
Whilst you see my example of positions on the page, as margins. I am looking at them as left and right sidebars, and headers and footers that allow page left (on top of left sidebar), top left of story, Top centre of story, top right of story, page top right sidebar, and similar vertically and in the footer. More advanced issues are if you permit additional stories then they could have independent Left Centre Right fixed and sticky headers and footers that appear only if they contain content. I hope my idea is clearer. Reagrds |
|
Here's something I wish to be possible with a new layout, even if not implemented right away: Toggle some kind of "change layout" mode and the page elements become drag'n drop that snap to different places as you drag them around. E.g you grab the sidebar and move it to the left page side. Or you grab a sidebar tab and move it into another position among the tabs. This would be a very user friendly "high-level hacking" approach to customize ones wiki. |
|
Found a couple very interesting side effects of anchor links in the new layout demo from #4473 (comment). Basically, anchor links will scroll down to bring the new item into view (at the correct position) but won't scroll up. Tested on Firefox and Chromium on Linux, both by clicking links and by typing the appropriate hash part into the URL (e.g., I edited my URL bar to read "layout.html#heading2" and pressed Enter). I won't have time to pin it down and create repro steps until a couple weeks from now, at which point I'll add screenshots and a proper repro. |
|
Although this is only partly related to the topic, see if it can give you ideas: I created a theme that, instead of using a single large CSS, loads CSS components that only perform a specific task. Components can use settings, the interface required for this is defined by the component itself. I store the current settings in a theme tiddler that lists what components it uses and includes the component settings in its fields so we can easily store and switch between different "sets". Exporting a theme actually means exporting theme ("set") tiddler and component tiddlers, so if someone imports it into their own wiki, they can use those components again in other theme in different combination.
I would find it a good idea if the page components would work similarly. Currently, there is no way to easily turn stylsheet tiddlers on and off (the only way to turn them off is to remove the system tag), based on this, it is likely that page components would work similarly, making it difficult for users to they can easily try different combinations. The importance of easy modification is told by Brad Victor in Inventing on Principle. |
|
@bimlas |
|
@bimlas - Just posted a comment on your wiki, but got a notice saying that Disqus comments are "currently in maintenance mode" so I'm not sure you saw it. So I'll reproduce it below.
|
Thanks for those, which are pretty timely as the whole discussion, as I was exploring a mobile friendlier TiddlyWiki. Do you know Bricks? I think that the approaches on Bricks Studio and yours are complementary, as both are modularizing CSS in TW, but Bricks if focused on speed, yours on live modifiability and the flex based TW of this issue opening a door for both. I wonder if we could have a live modifiable Modular theme in Bricks Studio that "compiles" to a pretty fast theme, for site delivery and offline reading.
I really like that talk. Recently I was playing trying to bridge Pharo and TiddlyWiki as both are two pretty powerful self referential metasystems with live modification support. The idea is to combine them with Fossil to build a "Pocket Infrastructures" toolkit to create and deliver hypertextual content in places with low/intermittent Internet connectivity. |
|
I got this new layout working 👍 |
|
Is there a demo? |
I've already implemented the layout in the OP in TWPub: I plan to work on it more within TWPub, but it will eventually become a core proposal. |
|
perfect @Jermolene, I didn't know about your TWPub project 👍 |
No worries, I'll update the OP. |
UPDATE 6th June 2021:
I've now implemented this new layout as part of the work on the https://twpub-tools.org/ project. I plan to work on it more there, working towards a proposal for the core:
https://github.com/TWPUB/TWPUB-Tools
We have a number of long-standing problems with the layout of the story river, sidebar, position sticky headings and any toolbars:
the current layout is the result of overlaying three independent components: the story river, the sidebar, and the new menu bar. Their layout is entirely independent: we just arrange margins and padding to try to stop them blotting each other out. That's the fundamental problem with the current layout that we keep running into: whenever we change the layout of one of those three page components we have to meticulously adjust the layout of the others.
It is proposed to explore an alternative layout based on CSS flexbox. It's entirely fluid, with the page components flowing to take up the available space. Flexbox gives us a lot of flexibility for how those components react to the screen size changing too.
As a first step, here's a mockup of TW5's layout built with flexbox: https://codepen.io/jermolene/pen/mdJBqGz
The implementation is pleasantly clean; there are no magic numbers, and everything lines up without having to do anything special. However, the required HTML structure is not compatible with the present page template.
The flexbox solution is adaptive; if one inserts another
.toolbarbeneath the closing</main>tag then one gets a toolbar fixed to the bottom of the window, with everything smoothly adjusting to make room. Additional sidebars can be added in the same way. CSS Grid requires the entire layout to specified in one place, and doesn't have that same adaptability. We need the adaptability because of the way that TW5 works: we want users to be able to add another horizontal bar by adding a new tiddler with the tag$:/tags/HorizBar(say), without having to fiddle with CSS as well. That's rather the point of this change, in factThe way that the layout proposed here works is that first the screen is divided into horizontal strips, one for the toolbar and one for the story river and sidebars. The so-called "main" strip is automatically resized to fit all of the strips onto the screen at once.
Then the main strip is further divided into vertical strips: the difference between a sidebar and a story river is that the sidebars have fixed width and the story river(s) expand to fill the available space.
Applying all of this to TiddlyWiki, there would be new system tags for adding horizontal strips, and for adding vertical strips within the main strip. Some of the strips would themselves be composed from system tags -- for example, the menu bar is composed from system tags identifying menu items.
For the record, I also did some initial experimentation with a CSS grid implementation, and concluded:
The text was updated successfully, but these errors were encountered: