empty.html should start with a "Centered story, fixed sidebar" setting.

[PMario]

Hi folks,

According to the feedback from empty.html should start with "fluid-fixed" layout I did create a new setting in the ControlPanel : Appearance : Theeme Tweaks

 - Centered story, fixed sidebar

If the option is set, the metrics elements, that can't be used are "grayd out".

The PR is at: https://github.com/Jermolene/TiddlyWiki5/pull/5800

Feedback is welcome.

-mario

[Frank Bruns-Ballhausen]

Hi Mario, we just had the pleasure, but others are welcome to read my opinion as well.

Not a bad idea as far as it goes. Better than the original alignment of the empty.html.
But I would like to see another variant "All centered". Of course, both side by side but shown together in the center.

[Soren Bjornstad]

While we're discussing story river layouts, I've been playing with the following odd-looking but surprisingly functional layout for a couple of days, in an attempt to make optimal use of the 24" monitors where I do most of my editing:

As you can see, the story river is centered, but tiddlers get wider when you go into edit mode, so there's additional space for a side-by-side preview when editing but lines don't get too long to comfortably read when viewing. I also changed the division between the editor and the preview to 70/30 instead of 50/50, which usually gets the paragraphs on the left and right to almost exactly line up, rather than the wikitext rapidly getting longer than the preview (a smaller difference like 60/40 might be a better compromise if you edit with a lot of images or transclusions).

CSS on top of the default theme and fluid-fixed layout:

div.tc-tiddler-frame { max-width: 60em; margin-left: auto; margin-right: auto; }

div.tc-tiddler-edit-frame { max-width: 90em; margin-left: auto; margin-right: auto; }

div.tc-tiddler-body { max-width: 50em; margin: auto; }

.tc-tiddler-frame .tc-tiddler-preview .tc-edit-texteditor { width: 69%; }

div.tc-tiddler-preview-preview { width: 29%; }

Still in alpha stages, and probably much too odd to implement in core, but maybe interesting to somebody. :-)

[Darth Mole]

@Soren,

I have been trying to make a two column view for my World Building project. The idea was that someone could be editing a Tiddler (entry) or writing a chapter (again a Tiddler) and then have the world details above in an isolated row that scrolled. Kind of like Stroll but instead of two columns it would have two rows to switch the Tiddlers between. 

However, your CSS gave me an idea and my question is, as I sit here shaking and jittering like I have waaaaaaaay too much sugar, can you tell me if my changes to the edit-frame css breaks anything in your mind? 

I think I figured out how I can, and now want to, have the edit and viewing breakdown. Again, I just want to make sure I'm not butchering something else without realizing it. Thank you so much if you can and for your CSS/idea!

div.tc-tiddler-frame { max-width: 60em; margin-left: auto; margin-right: auto; } 

div.tc-tiddler-edit-frame { max-width: 90em; margin-left: auto; margin-right: auto; max-height: 500px; overflow:auto; position: fixed; bottom: 0; z-index:2; } 

div.tc-tiddler-body { max-width: 50em; margin: auto; }  

.tc-tiddler-frame .tc-tiddler-preview .tc-edit-texteditor { width: 69%; } 

div.tc-tiddler-preview-preview { width: 29%; }

[Darth Mole]

*two row view for my World Building project. 

[PMario]

Hi Soren,

That's an interesting approach and I think it looks good. ... IMO it would be a very easy to create a theme on top of my new "Centered story, fixed sidebar" option.

It would need to add a new setting for "Editor width" in addition to the existing "Tiddler width" and there would be a new setting for the "Preview width".

I did experiment with a "slider-like" functionality in the middle of the edit-area and the preview-area but it looked ugly and didn't work. The wikitext complexity got out of control. ...

-mario

[PMario]

Hi Frank,

You are right. That looks nicer as a default. ... The setting I created fits my personal needs ;). ..

IMO it should be possible to define your setting that way:

 - Body width ... in pixel, em or % of the max-width ... which contains the story-river + the sidebar

 - Body / Sidebar ... ratio where only 1 width will be set. The other will be calculated. eg: 60% / (40% is calculated)

BUT .. It seems this will completely clash with the existing PageTemplate + CSS

Whatever I do - it always looks like this.

just some thoughts.

-mario

[PMario]

I think I found something

[Télumire]

Hello Mario,

In your preview the main story is off-centered when the side menu panel is open. Personally I think it would maybe be better if it stayed perfectly centered as long as there is space for it, to reduce distraction (the text moving around) :)
Otherwise, I love the centered story view, it's much more comfortable for reading long tiddlers !

[Soren Bjornstad]

Absolute positioning strikes me as likely to confuse TiddlyWiki's layout, but I'm mostly a “guess and check” CSS user so I can't explain why, except that I've tried to do it in the past and it hasn't worked very well. But your situation may be different.

Also, wouldn't that be applying the same absolute positioning to every tiddler in the story river, which could include both the details and the entry/chapter? You might be able to use data-tags to apply the special positioning/sizing only to one of the items.

[TiddlyTweeter]

Ciao Soren & all

It really strikes me that one of the TW gurus who understand it's CSS/HTML and the cascade that binds the two ...

... could probably give us a better TOOL to PLAY with layout dynamically???

TW is exceptionally good at dynamic recursion.

The layout is infinitely tweak-able. 

Some macro/tool that can dynamically make test-tweaking more intuitive I think would be good???

Just thoughts

TT

[PMario]

On Wednesday, June 16, 2021 at 2:24:04 PM UTC+2 Soren Bjornstad wrote:

Absolute positioning strikes me as likely to confuse TiddlyWiki's layout, but I'm mostly a “guess and check” CSS user so I can't explain why, except that I've tried to do it in the past and it hasn't worked very well. But your situation may be different.

Yea, the initial positioning is done with absolute positioning and margins to "push" the DIVs to the right position. ... As TW5 was created, there where no possibilities to use CSS calc(). Now every major browser supports it with about 98% browser coverage.

This makes things easier.

 

Also, wouldn't that be applying the same absolute positioning to every tiddler in the story river,

Centering is done with margin-left and margin-right both set to auto. and a max-width to the page container.

 

which could include both the details and the entry/chapter?

I don't understand this.

 

You might be able to use data-tags to apply the special positioning/sizing only to one of the items.

data-tags can be used to apply special formats depending an tags. .. That' not what we need here. ... We need a very generic way to center the story-river.

I'll try to publish a "kitchensink" version soon. So you can play with it.

-mario

[TiddlyTweeter]

Ciao PMario & Frank

Very interesting thread! 

Real end-looks/end-usage are the stakes.

PMario's "fits my personal needs" is a kinda understatement :-) ... I agree with him that ...

I do think it is true that DIFFERENT APPS (end-usages) often need DIFFERENT FACES (end-looks / UI).

My own PERSONAL thought on this in TW is we should try collectively to develop a methodology/tools so that it is EASIER to create new interfaces.

In a sense, at the moment, I think we making a saga where actually a simple tool might solve anyone's problem pretty easily???

Just thoughts

TT

 PMario wrote:

Hi Frank,

You are right. That looks nicer as a default. ... The setting I created fits my personal needs ;). ..

IMO it should be possible to define your setting that way ...

[PMario]

On Wednesday, June 16, 2021 at 4:48:48 PM UTC+2 TiddlyTweeter wrote:

It really strikes me that one of the TW gurus who understand it's CSS/HTML and the cascade that binds the two ...

... could probably give us a better TOOL to PLAY with layout dynamically???

This basically means to create the PageTemplate and the /vanilla CSS from scratch with a completely new concept in mind. ...

The existing layout and the CSS have been started prior to 2012 ... more than 10 years ago. ..

So having a closer look to eg: the CSS calc() function. FireFox started to implement it March 2011 and Chrome started March 2012.

Mobile browsers implemented the feature MAY 2021 ... Which basically means the feature can now be used safely. ...

The same thing is true for flexbox, and grid which are major improvements that _can_ make layout styling more consistent. ..

So now we are at a position to create a new and more dynamic layout. ... BUT we pretty much need to start from scratch, since grid and flexbox are fundamentally different philosophies.

vanilla CSS atm is close to 2500 lines of code.

-mario

[PMario]

On Wednesday, June 16, 2021 at 5:04:07 PM UTC+2 TiddlyTweeter wrote:

PMario's "fits my personal needs" is a kinda understatement :-) ... I agree with him that ...

I do think it is true that DIFFERENT APPS (end-usages) often need DIFFERENT FACES (end-looks / UI).

Yea, .. Most of the time I start to build new things, that are primarily useful for me. ... The second step is collecting feedback. Maybe someone else also likes it. ...

In this special case. Franks suggestion is ascetically more pleasing, than my initial configuration.

 - Franks suggestion imo makes more sense as an initial experience for new users.

 - My configuration still makes _some_ sense in a development environment. 

 

In a sense, at the moment, I think we making a saga where actually a simple tool might solve anyone's problem pretty easily???

"simple tool" ... I think you meant "simple to use tool" ... The backend side of this tool imo is complex and will need a lot of thought. As I wrote in my last post.

-mario

[TiddlyTweeter]

PMario wrote...

... vanilla CSS atm is close to 2500 lines of code.

Right! It is a major achievement! It is pretty astonishing!

The end-use issues partly arise from "HOW do you know?"  what directives in that vast stylesheet(s) system are active where and when?

The developer tools will retro-supply answers, but the sheer complexity of the cascade can, sometimes, make it hard to fathom out EXACTLY what to do to change the UI in a consistent fashion.

Just a comment

TT

[TiddlyTweeter]

PMario wrote ...

... "simple tool" ... I think you meant "simple to use tool" ... The backend side of this tool imo is complex and will need a lot of thought. As I wrote in my last post.

HaHa! I love your semantic appreciation of English!

Right! I did not really mean making it is easy. I am not a programmer by either craft or orientation. 

WHAT am I saying? Merely that interactive tools for CSS WILL WORK in TW since it is a full-on dynamic system.

AND I do suspect that we might be able to make a much better job of providing simple "CSS use tools" than is currently the case.

Just thoughts

TT

[Frank Bruns-Ballhausen]

Hello everybody,

I think a "simple tool" like TiddlyTweeter wants is already there. It is the basic settings. The community shows that for people who play a bit with it (and know CSS), many different designs are possible even without such a tool.

You can still wish for it, of course :-)

But perhaps a different presentation of the setting options would be useful. For example, instead of the typical table (property on the left, input field on the right), a simplified representation of the boxes and margins, as used in TiddlyWikki, might be useful. This might also save translation texts, because it would then be largely self-explanatory.

... and because it is used so often here...  Just thoughts ;-)

» FBB

[TW Tones]

Some thoughts;

In a related need I created a sidebar width tool - attached. If you look at how it works I have to concatenate the N with px wide. This value permits one number to change the relationship using fluid story and fixed sidebar. I would like to see the number and units stored separately to allow such manipulation. There should be css values that the user can set and save including in a layout, to manipulate the whole layout. This would include locations for a left sidebar, or settings centred story etc ...

As we present custom layouts we should be incorporating hidden elements that can be made active by the wiki designer.

I am a strong believer that the layout should be a layer which can be replaced. Kind of making tiddlywiki and engine layer, a layout layer and a customised UI elements layer.

Regards

Tones

Regards

Tones

[Brian Radspinner]

@Tones, I don't know if you can make a tool out of it but you can use CSS variables to get a start with one element's width effecting another's...

body.tc-body {

   --sidebarWidth: 33.33%;

}

.tc-sidebar-scrollable {

   width: var(--sidebarWidth);

}

.tc-story-river {

   width: calc(100% - var(--sidebarWidth) - 10px);

}

Adjusting the --sidebarWidth variable will cause both the sidebar and story river widths to change.

[TW Tones]

Brian,

That would be useful but I am not sure if we can use var() as its a function. Changing  $:/themes/tiddlywiki/vanilla/metrics/sidebarwidth is sufficient.

Regards

Tones

[PMario]

Hi Brian,

That's exactly the behaviour I was talking about in an earlier post here in the thread. ... But stuff like this has to be considered from the very beginning.

At the moment we use wikitext transclusions to "simulate" the new CSS features. ...

On Thursday, June 17, 2021 at 2:55:08 AM UTC+2 Brian Radspinner wrote:

@Tones, I don't know if you can make a tool out of it but you can use CSS variables to get a start with one element's width effecting another's...

body.tc-body {

   --sidebarWidth: 33.33%;

}

This doesn't work for us in TW. Since we want the 33.33% to be dynamically assigned from a value a user can change in the UI and not in a CSS ...

Changing a CSS isn't considered to be a "simple tool"  ... Changing settings from the UI "is". .. So we have to combine new CSS functions with the power of our existing wikitext transclusions.

just some thoughts

mario

[PMario]

I folks,

I did just upload a "test version" https://pmario.github.io/kitchensink/5800-centered-fluid-layout.html where you can play with.

BUT

It is a theme now. I did use the existing Centralised theme and pimped it a bit. See the animated gif.

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 900px
• The "width breakpoint" where it switches to "mobile mode" has been set to 1260
• 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.

The PR is

have fun!

mario

[David Gifford]

Feedback on this idea and the example link:

1. On my 15" laptop, the sidebar is way too scrunched to be useful.

2. When I reduced my browser window from full to about a centimeter less wide, it switches to "mobile" layout and the sidebar moves above the story river.

3. So #1 and #2 tell me this is a solution created for developers that have super wide screens, but not taking into account those of us with average sized screens.

4. If this were core, this would mean that upon upgrading, I would need to a) know what to do to fix it, and b) go in and do it. For every file I upgrade. This is not a "backwards-compatible" solution. It would be better to leave it as it has always been, with the original two options, and add this as a third option. But not make this third option default.

5. Your example takes away fixed story, fluid river, which is my default option. Are you proposing eliminating that option?

6. I did like someone's suggestion of "All centered". Then have a field to adjust the width of the margins, and a slider to adjust the %'s of story vs sidebar. But again, this should not be default, but a third option.

[David Gifford]

For reference, I am attaching images of what full screen and almost full screen look like on my average-sized laptop, 15" screen.

[Frank Bruns-Ballhausen]

Hallo,

I am of the opinion that in the case of centring, the width of the story must always be a percentage (e.g. 60%).

The sidebar must have a minimum width. For example 300px. We have two problems with this. Firstly, the breakpoint for the sidebar no longer works.

Consequently, falling below the page width must be used for this breakpoint.

The calculation for the attributes left of the class .tc-sidebar-scrollable and .tc-story-river should be reviewed or calculated anew.

The story must not be in the middle because otherwise the sidebar might fall out of the window on the righthand side.

As far as the implementation is concerned, I don't yet know exactly where to change it because I don't yet know how all the elements are connected and which values have to be changed at which point.

I tested these values using Mario's example, directly in the browser.

By, Frank

[PMario]

On Thursday, June 17, 2021 at 2:47:59 PM UTC+2 David Gifford wrote:

1. On my 15" laptop, the sidebar is way too scrunched to be useful.

So you think 800px would be a better default width of the story river. .. You know, that you can change those settings. ..

 

2. When I reduced my browser window from full to about a centimeter less wide, it switches to "mobile" layout and the sidebar moves above the story river.

You only need to change the Sidebar Breakpoint. ... But if your sidebar is already "scrunched", than this is the right behaviour. .. Which resolution does your laptop have? ... The GIF uses 1920 x 634 ... So it's not full-hd width.

 

3. So #1 and #2 tell me this is a solution created for developers that have super wide screens, but not taking into account those of us with average sized screens.

As I wrote may be 800px as default story-river. ...

 

4. If this were core, this would mean that upon upgrading, I would need to a) know what to do to fix it, and b) go in and do it. For every file I upgrade. This is not a "backwards-compatible" solution. It would be better to leave it as it has always been, with the original two options, and add this as a third option. But not make this third option default.

This is easy to change in the ControlPanel : Appearance : Theme Tweaks - settings. ... The Storywidth and the Sidebar Breakpoint settings can be adjusted.

Since these are the only 2 settings left, I thought it should be easier to experiment with them.

5. Your example takes away fixed story, fluid river, which is my default option. Are you proposing eliminating that option?

This is the Centralised theme. .. There is no problem to switch back to Snowwhite as shown in the GIF. ... At the moment it isn't possible to have all 3 options based on the "vanilla" theme, since "Tight" and "Tight and Heavier" theme break the "centered" settings

 

6. I did like someone's suggestion of "All centered". Then have a field to adjust the width of the margins, and a slider to adjust the %'s of story vs sidebar. But again, this should not be default, but a third option.

As written above. Just go to ControlPanel : Appearance : Theme Tweaks and change your settings.

-mario

[PMario]

I did upload a new version with 700px default story-river and 1060 as the breakpoint.

On Thursday, June 17, 2021 at 11:34:52 PM UTC+2 f.brunsb...@gmail.com wrote:

I am of the opinion that in the case of centring, the width of the story must always be a percentage (e.g. 60%).

On my PC screen 60% means 2064px .. The screen is 3440 x 1440 - 34" ... So that's not an option.

 

The sidebar must have a minimum width. For example 300px. We have two problems with this. Firstly, the breakpoint for the sidebar no longer works.

Consequently, falling below the page width must be used for this breakpoint.

The breakpoint can be adjusted. See the other post.

------------

On my PC the new settings looks like this:

have fun!

mario

[David Gifford]

Hi PMario

My display is at the recommended 1920 x 1080. That is a typical laptop setting.

You keep repeating 'just change it in the control panel', but it wouldn't be fair that I and everyone who uses more typical screen sizes like mine, and tools like Muuri and Stroll, would have to go through a 4 or 5 step process after updating every file we want to update to the next version of TW, and any new empty we download, because of your subjective preference that your centralized should be the default theme, and because you have a monster-sized screen and-or have the resolution so high that the text is really small.

Like I wrote before, yes, by all means, make changes to the centralized theme, just don't make it default. That way if you want it, great. Since you say the process is so easy, then you can do that.

[PMario]

On Friday, June 18, 2021 at 12:17:31 AM UTC+2 David Gifford wrote:

My display is at the recommended 1920 x 1080. That is a typical laptop setting.

That's strange. Your screen shot shows much less left and right margin than my initial GIF and it has 1920 x 634 .. So the 2 screenshots should have similar margins but they don't

In your screenshot.jpg image the story river uses 1222px .. That's not the 900px which is in the settings. ... So is there a default browser zoom eg: 130% or OS zoom ?

-mario

[PMario]

On Friday, June 18, 2021 at 12:17:31 AM UTC+2 David Gifford wrote:

You keep repeating 'just change it in the control panel', but it wouldn't be fair that I and everyone who uses more typical screen sizes like mine, and tools like Muuri and Stroll, would have to go through a 4 or 5 step process after updating every file we want to update to the next version of TW, and any new empty we download, because of your subjective preference that your centralized should be the default theme, and because you have a monster-sized screen and-or have the resolution so high that the text is really small.

That's exactly the point. A screenshot of tiddlywiki.com/empty.html looks like this with a resolution of 1920 x 1080

If it looks different in your browser, than you have set a zoom level set somewhere.

We did have several requests here in the group and at GitHub that did complain about empty.html using too less screen width. .. That's the reason why I did make a proposal.

In the screenshot above you can see, that empty only uses about 50% of the screen width, which imo is a problem.

 

Like I wrote before, yes, by all means, make changes to the centralized theme, just don't make it default. That way if you want it, great. Since you say the process is so easy, then you can do that.

From my point of view everyone who starts with empty.html has to go through 4-5 steps to adjust the layout, that it is usable.

If your resolution is 1920 x 1080 as the screenshot above and your zoom level is 100% I'm pretty sure you have to make those steps too.

-mario

[David Gifford]

Well...that's interesting...I had display scale at 150%, so I switched it to the recommended 125% ...now I see what you mean...

Well, okay then, I take it all back...Now I need to rethink my sidebar strategies...

[springer]

Soren and all,

The idea of asymmetrical edit/preview panes is appealing!

In some cases, the edit window should be relatively wide (where markup source is longer than rendered result), but in other cases, the preview actually requires much *more* space than the edit box (because of transclusions, dynamic tables, etc.). 

I wonder how hard it would be to make the column gutter moveable, and/or to get the preview to recognize (with some quick-and-dirty approximation) what kind of ratio might be suitable.

-Springer

[Brian Radspinner]

I've currently got a 3-column layout going: center is the normal view mode; edit mode has the preview to the left and editor in the center; sidebar the right column where I often display full tiddlers side-by-side with the story river.

[TW Tones]

Folks,

While on this layout question I have always felt the default in Mobile mode should be withe the sidebar closed or at the bottom as the footer. This is even more so when we now have the menu bar available.

Personally the default view on desktop does not suit me, I immediately switch to fixed sidebar, fluid story to make full use of the real-estate. So even the centred view would not suit me unless I was considering making use of a Left hand sideBar. I have felt since TW5 that the old TWC left hand side bar should also be a core option, such as having a left/sidebar segment and left sidebar tabs etc..., perhaps not in use but only a tag away.

A fully addressable page layout with elements that appear if used could be achieved with flex and other layout methods. The layout in the thread would just me one configuration in a large set of possible layouts driven purely by the existence of contents/tiddlers so tagged.

Regards

Tones

[PMario]

On Friday, June 18, 2021 at 7:02:32 AM UTC+2 TW Tones wrote:

While on this layout question I have always felt the default in Mobile mode should be withe the sidebar closed or at the bottom as the footer. This is even more so when we now have the menu bar available.

That's right. But the "menu bar" plugin isn't part of the empty-edition.

-m

[Frank Bruns-Ballhausen]

Hello folks,

I like Brian's idea of widening the tiddlers to the left (up to the available width) when editing. But this makes the whole layout very "unsteady".

Wouldn't it be worth thinking about offering not only switching between with and without preview when editing. But a third variant, which only shows the preview?
This is what ReText (a Markdown editor) does, for example. The best way to use this function is via a keyboard shortcut.
Just an idea. This is certainly not the right topic for it

Apopos topic. @pmario I think I have suppressed the possibility that this was about the empty.html, and I was too focused on my view. Sorry.

Apart from that, variable widths depending on your own screen would still be worth considering for a default setting?

You could use a min-width as well as a max-width for the Storyriver. Designers and graphic artists like to work with the "golden ratio".

Even though, like Mario, I think a story that is too broad with long sentences is hard to read. Here a good compromise could be found with a variable width.

Because we all know, that never fits all people.

Just an idea. - Frank

[TiddlyTweeter]

Ciao Frank.brunsb... & all,

f.brunsb...@gmail.com wrote

Apart from that, variable widths depending on your own screen would still be worth considering for a default setting?

You could use a min-width as well as a max-width for the Storyriver. Designers and graphic artists like to work with the "golden ratio".

Right. The "golden ratio" is kinda helpful. TBH I use it in photography (visual medium) a lot, but the web is also "other" (largely textually organised medium) .

If I ever got time I'd love to do an internet version of MEDIEVAL MANUSCRIPTS that fill the page fully, all INLINE (in net jargon). Paragraphs are indicated by RUBICATION (starting paras in Red), not with blank links.

    Truth is, all this stuff is just conventions! 

Line length MAYBE needs to be CENTRALISED in TW at 80 chars / line for easier read. 

But if we went MEDIEVAL the font would be 3 times larger. 80 characters or less per screen width.

MY POINT is what we need is better FLEX on CSS not "perfect solutions" :-) 

Just my 2 cents!

TT

[TiddlyTweeter]

Ciao PMario

I'm revisiting this as I think it is interesting. BUT I have a problem.

I completely understand you don't want to read very long lines. And an UN-centered main column is not always ideal.

BUT, let us take a real case where the metaphor breaks down. 

SAY, I want a column for the reader in the middle (much like you) AND I want easy access to 100% full width too ... 

... like this which permits two 50% iframes on desktop side by side ...

Just (probably annoying) illustration, but IMO we need FLEX on CSS (a better way to tweak), not specific solutions per se.

Just a comment. I do appreciate your concern to make things better.

Very best wishes

TT 

[TW Tones]

Mario,

With or without the menu bar plugin I expect people are more likely to want "their content", the first tiddler open to be the launch point for mobile wikis not dropping then user on the "sideBar" where one has to choose from a tab, many which are not relevant, to proceed. 

It would seem to me that an option to determine if the sidebar tab  is open/closed, on the top or bottom in mobile mode specifically is a desirable configuration option. If we look at other mobile themes we tend to see this implemented typically with a menu bar any way. It seems the default mobile mode should be a closed sidebar with a hamburger menu to open the side bar, in the window.

Regards

Tones