Change the width of the sidebar#445

While on the subject of the sidebar, can you make the width adjustable? On high-res desktops there is way more width that I can use (see screenshot) while the topics on the sidebar are word wrapped to 2-3 lines, making them hard to read and taking up too much space.

By dragging on the edge of the sidebar, I can increase the width, causing most of the topics to occupy just one line.

I would also love to see the sidebar text drop a few point sizes and tighten up to allow for more information on the screen. Perhaps this could be a setting as other users may feel differently.

Like this?

This is a simple implementation, it sets the width at the user profile level and it applies to all wikis.

Is this what you would expect or would you want to be able to set different sizes per wiki?

In terms of the font size, would you expect the same behaviour, in that it applies to your user profile globally, or the ability to set it per wiki.

This looks perfect. Would want settings to apply to all Wikis as you show. Same with the text. Thanks!

Good news!

Your Loom video did not show how text wrap will work but I am hoping that the topic and document names will take advantage of the sidebar width so that as I change the width, the topic and doc names will wrap or unwrap to occupy a single line if the sidebar width is expanded beyond the width of the text.

I also not sure if I would prefer the text to truncate after 2-3 lines rather than have just one or two words on each line. At some point, I think I would prefer to see just the first few words rather than a multi-line “stack” of ALL the words. Such a stack is hard to read and at some point is worse than seeing a partial title.

Offering the option to reduce the text size will help this issue. By reducing the sidebar font size, more words should fit on each line as the sidebar width is increased.

Finally, now that I think about it, I would prefer that the width of the sidebar be set PER WIKI. Some wikis may have many more nesting levels than others so a width that can be set for each wiki would make more sense. Even better, can you make the sidebar width an option to be global or local?

Sorry to lay all of this on you now.

Thanks.

Yeah I think per-wiki resizing also makes sense now that you mention it.

One potential option is to have resizing be global by default and have a wiki setting for custom sidebar size. Once checked, the wikis sidebar size is sized independently from the others.

Would that work for you?

In terms of truncation, one option is to truncate after a certain folder depth (e.g. 3 folders deep) on a single line.
Another is to generally truncate after 2-3 lines as you suggest.

I’ll push up the global resize first to get feedback, then I’ll open a ticket up for per-wiki resizing and text truncation.

I’d be happy with the default global sidebar width and a Settings checkbox to exempt the wiki from the default.

Regrading truncation, my first choice is to have ALL topic and doc title text unwrap to a single line if the sidebar width is adequate to show all the text.

If the sidebar width is decreased, I’d like to see the text start wrapping to a max of 2 lines with the excess text truncated with “…” added to the end.

I’d also like to see the doc and file name text a few point sizes smaller which will help avoid the truncation, and also make it more obvious which sidebar text is a folder vs. document or file. Also maybe drop the weight of this smaller text?

See the attached sidebar comparison.

Pushed up the initial resize, it applies it globally.

Works great!

Do you eventually plan to restrict the text wrapping to a minimum of 15 characters or so per line? With the word wrapping now, when you reduce the sidebar width, it quickly becomes unusable. Would also be nice to add an ellipsis at the end of any truncated text.

One more thing I might like to see in the sidebard is a line height reduction of a few points. There is lots of extra spacing in the siderbar now. While it looks cleaner, that restricts how much you can see without scrolling.

QUESTION: What does the Setting, “Link to” Menu do. I cannot see any difference with and without it checked.

Per your first question, yes to both.
I’ll open up a new ticket with these details in the coming days that covers everything discussed here.

QUESTION: What does the Setting, “Link to” Menu do. I cannot see any difference with and without it checked.

When you highlight some text in a page, it shows a menu that allows you to link to another page in the wiki.

This was previously enabled by default, now it is off by default as some people found it annoying when selecting text.

I get it now. I tried it and it works, but I can see that it might be annoying.

However, in the process of adding the menu link and then deleting it by opening the Doc and using the “Remove link” menu item, I think I found a bug.

Now, after adding this Link Menu and removing it, my image at the top of the page does not obey Cropping. I.e., the image shows correctly in the Doc view but not in the Wiki view where it shows the image as if the cropping is not recognized and so shifts up the image. See attached file FIG 1.

I left the image cropping tool visible in the Doc screenshot FIG 2, and FIG 3 shows what the Wiki page used to look like. If I remove the cropping, the image displays correctly, albeit with too much whitespace above and below.

I cannot get the cropping to work now. It doesn’t matter if the “Link To menu” is checked or not. It appears that any document I create now has the cropping problem but all previous documents that were created before the “Link To menu” feature was added still work correctly.

As a final test, I recreated an older document that used cropped images and added it back to the current YANW. Now, the cropping that worked correctly previously is NOT working correctly.

If you would like to get together and share my screen so you can better see what’s going on, let’s schedule a Google Meet. Also, feel free to call me at (949) 646-8877 anytime between 7 AM and 6 PM Pacific time.

Thanks,
Paul Stary

If you could copy an example here I can take a look.
https://youneedawiki.com/app/page/1RDZPv294UeSgUuzwJA7gFLYc8PdZyzCyKVnq7SZuMgc?p=1ni-SM5L2no2AR2mLPe5COuaHgVl7shTm

I’ve added (2) of my problem pages and a comments page to the wiki you linked. Cool use of your own product to look at this problem!

Thanks Paul I can recreate the issue. I’ve opened a ticket here:
https://feedback.youneedawiki.com/449

I’ve added this to the rewrite ticket as it is simpler to fix in the new codebase. https://feedback.youneedawiki.com/438

As a temporary workaround I would suggest cropping the image in an image editor like https://www.figma.com and pasting that into the document.