search

TiddlyWiki / TiddlyWiki5

A self-contained JavaScript wiki for the browser, Node.js, AWS Lambda etc.
https://tiddlywiki.com/
Other
8k stars 1.18k forks source link

Improve page layout #4473

Open Jermolene opened 4 years ago

Jermolene commented 4 years ago

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

image

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 .toolbar beneath 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 fact

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.

For the record, I also did some initial experimentation with a CSS grid implementation, and concluded:

kookma commented 4 years ago

@Jermolene Please also take in account the animation effects and the way storyview like zoomin, classic and solo work!

I hope this PR could address also the odd behavior of those story views. It should be possible to simply go to presentation mode (e.g. fullscreen + focused tiddler cover the whole viewport)

kookma commented 4 years ago

@Jermolene

The https://codepen.io/jermolene/pen/mdJBqGz resembles the single page layout which is quite useful to create website using Tiddlywiki.

kookma commented 4 years ago

@Jermolene For having two scrollbars, I see the below template https://colorlib.com/preview/#vcard2

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.

Jermolene commented 4 years ago

Hi @kookma

Please also take in account the animation effects and the way storyview like zoomin, classic and solo work!

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.

It should be possible to simply go to presentation mode (e.g. fullscreen + focused tiddler cover the whole viewport)

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.

For having two scrollbars, I see the below template. Look at the very tiny scrollbar under description.

The problem isn't that there two scrollbars, it's that the positioning of them is currently wrong.

Jermolene commented 4 years ago

I've updated the original post with some notes about CSS grid.

kookma commented 4 years ago

@Jermolene Thank for clarification. By the way what I expect is in a page layout overhaul, those issues and drawbacks already addressed should be take in account. Also the layout should dynamically lend itself to different device sizes nowadays are used.

Thank you again!

kookma commented 4 years ago

Hi @kookma

Please also take in account the animation effects and the way storyview like zoomin, classic and solo work!

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.

True!

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.

That is right! I hope we could have solo final release soon.

twMat commented 4 years ago

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...

One obvious conclusion is that the required HTML structure is not compatible with the present page template.

...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.

AnthonyMuscio commented 4 years ago

Folks, I applaud your work on this but would ask if you can consider the following

Regards Tony

Jermolene commented 4 years ago

Hi @AnthonyMuscio

Make the page template (more) plugable and selectable, this could allow others to innovate

We will probably make the page template switchable, but I'm not sure what else you're thinking of here.

Perhaps a page template could revert to a default on a particular browser eg IE11?

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.

a special view that highlights each area and the tags required to have content appear there would facilitate use, even if this is provided as a separate plugin, or utility edition.

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.

A special view that provides interactive resizing of the relationship between various page elements may be as good or better than developing a whole new page layout, as long as we have catered for all possible elements including floating ones.

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.

kookma commented 4 years ago

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

twMat commented 4 years ago

@kookma - what you describe is known as The Holy Grail layout (because).

I just realized that the ideal might be two right sidebars. One with the usual tools and one empty/collapsed. It is not all uncommon that the user wants a right side public menu (after he hides the tool sidebar).

pmario commented 4 years ago

I'd like to have several story rivers. 3 or 4 make a nice fit for ultra-wide screens

Jermolene commented 4 years ago

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).

kookma commented 4 years ago

@Jermolene

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. Here I dont want to have holy grid in view, but I mean just placeholders, on demand can be revealed and used.

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.

Jermolene commented 4 years ago

Hi @kookma

Question: does you 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.

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.

I love the current right sidebar and fluid storyriver, but in some applications like software tutorial e.g

Yes, the layout proposed here supports arrangements like a left sidebar and a footer.

Jermolene commented 4 years ago

I've updated the CodePen with buttons to create/delete page components.

image
Jermolene commented 4 years ago

In case you want to experiment without the CodePen paraphernalia, here's a plain HTML version.

layout.html.zip

kookma commented 4 years ago

@Jermolene This is absolutely great! With this layout one can make different web apps.

kookma commented 4 years ago

@Jermolene

I did some experiments. It is really cool! Good to add ''Remove All Story rivers" just when playing :-). It is full of fun!

I love the immobilize header/footer/sidebar. I intentionally do not use sticky! With this layout making software tutorial/manual like Sphinex is a piece of cake.

AnthonyMuscio commented 4 years ago

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...

page-layout

kookma commented 4 years ago

@Jermolene

In case you want to experiment without the CodePen paraphernalia, here's a plain HTML version.

layout.html.zip

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: Story river is good to have a footer (bottom bar). This is good when TW is used on small screen (or even lower resolution screen) and it is better on scroll bottom bar move!

I think the next ingredient is to see how layout is responsive on different screen size!

Jermolene commented 4 years ago

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?

Jermolene commented 4 years ago

Hi @kookma I'm glad you're enjoying it!

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:

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.

I think the next ingredient is to see how layout is responsive on different screen size!

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.

BurningTreeC commented 4 years ago

This layout is very fun to play with, thanks @Jermolene for the pen and the mockup html :smile:

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

BurningTreeC commented 4 years ago

I thought it's probably the pagescroller that needs to get the correct scrolling element

Jermolene commented 4 years ago

Hi @BurningTreeC that's correct, rather than using CSS overflow: scroll we need to use a <$scrollable> widget.

BurningTreeC commented 4 years ago

Nice to read that there's a plan @Jermolene :+1:

AnthonyMuscio commented 4 years ago

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 Androidhttps://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 @AnthonyMusciohttps://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 GitHubhttps://github.com/Jermolene/TiddlyWiki5/issues/4473#issuecomment-598637082, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHQ7DEWCPD23FREZTPNBRK3RHH6A7ANCNFSM4LC36EWA.

Jermolene commented 4 years ago

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.

joshuafontany commented 4 years ago

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 notifications@github.com 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 https://github.com/Jermolene/TiddlyWiki5/issues/4473#issuecomment-598689542, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFOMB2LBYNDKP5ILUUDVTLRHIOZHANCNFSM4LC36EWA .

AnthonyMuscio commented 4 years ago

Jeremy,

Hi @AnthonyMuscio I'd really like to understand what you're proposing. Perhaps some sketches would help?

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? I could produce a detailed specification if you would like

Thanks for your patience.

I am inspired by what you have already shared.

AnthonyMuscio commented 4 years ago

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".

Jermolene commented 4 years ago

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.

dubiouscript commented 4 years ago

scanningg through the above and trying to grock 'wtf is flexbox'

i found this (Full-Screen Layout using Flexbox)

http://bl.ocks.org/jfsiii/5380802#aGrail

AnthonyMuscio commented 4 years ago

Jeremy,

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.

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 Tony

twMat commented 4 years ago

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.

rmunn commented 3 years ago

Found a couple very interesting side effects of anchor links in the new layout demo from https://github.com/Jermolene/TiddlyWiki5/issues/4473#issuecomment-598181323. 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.

bimlas commented 3 years ago

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.

kookma commented 3 years ago

@bimlas Your modular approach is highly appreciated. TW itself is modular, see how simple one can add a sidebar tab by assigning proper tag to a tiddler. Why not having this for theme! Right now the Tiddlywiki Theme hacking is out of knowledge of most beginner and intermediate users, one reason is the complexity of css is used. So I recommend your approach and hope we could have a similar design for core themes.

rmunn commented 3 years ago

@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.

Although I do have a Disqus account, I'm starting to think it's a bad idea to use Disqus due to privacy concerns (they're an ad company and use what you post to figure out how to target ads to you, and they have sold user data without users' consent). See https://markosaric.com/remove-disqus/ for the problem and https://ourcodeworld.com/articles/read/1265/top-7-best-open-source-self-hosted-comment-system-alternatives-to-disqus for some alternatives. I haven't explored any of them yet, but https://github.com/schn4ck/schnack looks like the best alternative for a TiddlyWiki comment system as it's written in nothing but Javascript and CSS.

offray commented 3 years ago

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.

* Demo: https://bimlas.gitlab.io/tw5-modular-theme-maple-palette/

* GG thread: https://groups.google.com/g/tiddlywiki/c/p98mltuihyI

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 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.

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.

BurningTreeC commented 3 years ago

I got this new layout working 👍 @Jermolene, we could add this as a second page layout, what do you think?

pmario commented 3 years ago

Is there a demo?

Jermolene commented 3 years ago

I got this new layout working 👍 @Jermolene, we could add this as a second page layout, what do you think?

I've already implemented the layout in the OP in TWPub:

https://twpub-tools.org/

I plan to work on it more within TWPub, but it will eventually become a core proposal.

BurningTreeC commented 3 years ago

perfect @Jermolene, I didn't know about your TWPub project 👍

Jermolene commented 3 years ago

perfect @Jermolene, I didn't know about your TWPub project 👍

No worries, I'll update the OP.