[Feature Request] reduce the size of sidebar when it is hidden

[BasilTomato]

Is your feature request related to a problem? Please describe. In the new 3.0 version the "hidden" sidebar mode still occupies around 1/5 of the horizontal screen space. It is quite frustrating in case of mobile screens, there was definitely more screen space available in version 2.0.

Describe the solution you'd like Please make the sidebar completely hidden, at least in case of mobile browsers. As far as I can remember in version 2.0 only a thin line was shown.

Additional context n/a

[brendanperry]

While I like the new design, I feel like this is a valid point. A lot of space is lost on a phone.

An idea I would propose is adding a full screen option.

In addition to a button somewhere, a slide to the left is the natural way that I want to do it and I think would fit the workflow well.

[johnozbay]

Hello all!

We're actively looking into how we can make better use of the mobile screen real estate this week, and we're going to make this even better very soon. I think it's important to clarify why we made it this way, and it'll make a lot more sense.

In the next major release (let's call it v3.1), we'll be releasing "print-layout" and "continuous-layout". So your documents will have print-accurate rendering like A4 or US-Letter etc, and alternatively, you'll have the ability to select continuous-layout, and use Cryptee Docs sort of like a note-keeping app, with less emphasis on the screen-width.

This will mean that in the print-layout mode, your actual editor width will be less important, since we'll have to keep the font-size paper-relative / print-accurate. So if you're seeing the page at 25% zoom, you'll have a bunch of tiny pages in the editor area, and if you're seeing the page at 200% zoom, you'll have the top left quarter of the page visible, and will be able to pan it etc.

On larger screens, the tools for this will be on the right (where all the other active/open document's tools are) And on mobile they will be in the sidebar, (also where all the other active / open documents' tools are)

The reason why we made the sidebar as large and permanent, is so that we can add the print-layout selection / margins / paper size etc tools in there. (or if the screen is too small, we're thinking of adding extra pan / zoom tools as well so that you can quickly explore even gigantic multi-page documents.)

In fact, we've actually shipped parts of this with v3 already, it's just hidden at the moment 😅

https://github.com/cryptee/web-client/blob/3404467b740fbe4a407585bfd715f33e2a4aa259/source/imports/app/docs-panel-pagesetup.kit#L1-L48

Here's how it looks like :

Needless to say the design of this panel is a work in progress, and will absolutely change once it's ready for primetime. But I hope this gives a good idea as to why we took this strange design decision.

So now that you know the backstory –  I've got a couple questions and I would love to hear your opinions on this :

---

1) If we were to hide the left sidebar entirely, how would you hint to users how / where to find the sidebar, how to open the sidebar? (i.e. an arrow in the bottom left corner of the screen etc?)

2) How would you feel about a sidebar that hides itself when the editor receives focus, but shows back up if you hide the virtual keyboard?

3) If we were to hide the sidebar entirely, where would you rather put the document action buttons on the bottom of the sidebar?

– One important thing to keep in mind : while the document is visible, the bottom of the sidebar shows document actions, and while the sidebar is open and folders list is visible, the bottom of the sidebar shows folder actions (i.e. show / hide archived folders, summon folders etc) So the functionality of this area changes depending on whether if the sidebar is open/closed, and what it's showing.

4) If we were to make the sidebar thinner on smaller screens, but not hide it entirely, so that both right and left handed users can still grab and pull it open easily :

4a ) Can you approximately tell what would be a comfortable sidebar-width for you? 4b ) What would be a comfortable writing width be for you? (if we were to try to find a compromise / middle-ground)

---

Looking forward to hearing what you think, and cannot wait to ship these features very soon!

Best, J

[johnozbay]

On and almost forgot – this is related to #58 ✌🏻

[BasilTomato]

Hello johnozbay,

Thanks for the quick and detailed explanation!

Regarding the questions:

1) If we were to hide the left sidebar entirely, how would you hint to users how / where to find the sidebar, how to open the sidebar? (i.e. an arrow in the bottom left corner of the screen etc?) An icon in the bottom left would be quite good solution, it is not distracting.

2) How would you feel about a sidebar that hides itself when the editor receives focus, but shows back up if you hide the virtual keyboard? It is very handy if the sidebar auto-hides itself when the editor receives focus. At the same time it would be very distracting if it auto-shows when the virtual keyboard is closed, eg.: in case of scrolling up/down I tend to close the virtual keyboard to be able to see as much document content as possible.

3) If we were to hide the sidebar entirely, where would you rather put the document action buttons on the bottom of the sidebar? I don't really have opinion on this, rarely use the document action buttons.

4) If we were to make the sidebar thinner on smaller screens, but not hide it entirely, so that both right and left handed users can still grab and pull it open easily : 4a ) Can you approximately tell what would be a comfortable sidebar-width for you? 4b ) What would be a comfortable writing width be for you? (if we were to try to find a compromise / middle-ground) Not sure it is possible to have an optimal width because there is different screen size, resolution and aspect ratio of various devices.

[brendanperry]

2) I don't think the auto hide would work well because I drop my keyboard a lot just to read things and it's hard to read when the width is small. Maybe it is because of other note taking apps that I have used in the past, but it just doesn't feel as natural when I'm missing part of the screen.

One thing I notice is on mobile, the bottom right corner's question mark overlaps text and it's hard to tell it is even there. That may be a separate issue in itself, but I would rather have a full screen button there to maximize / minimize. Like I mentioned before, it could be initiated with a swipe left which is currently not used at this screen.

4) If we have to keep the sidebar at all times, then I would cut the width in half. As far as I can see, the only reason it is so big is because of the logo and not the sidebar items. I'd rather cut the logo and get more space. I know it serves as a button too but you could have it back in one swipe.

On a related note, the buttons at the top of the sidebar seem out of place. When I am writing on mobile, I don't feel like I need the ability to jump to recent docs or create a new note. I would expect a backwards navigation for those actions.

I suppose if you removed the entire top button set of the sidebar and put in the buttons at the top of the document (checklist, table, etc) you could save space on top too.

[johnozbay]

Hello everyone!

I'm delighted to let you know that after months of experimenting, designing, running tests and doing math, we're getting rid of the sidebar entirely! 🎉

Background

First off – So sorry it took us so long, but I promise it's for a good reason. We needed the document action buttons to live somewhere (where you can do things like export document / get document info / turn on spellchecker / see table of contents etc) and they lived in the sidebar while the document was open.

If we were to get rid of the sidebar, the only place where we could move them was to the top of the document, but that meant that we had to get rid of some block-level tools (create new table / create checklist / upload inline image etc) – But we couldn't put these in the tooltips / pop-ups, because you need to be able to press these buttons even when some text isn't selected.

We thought the best solution is to move all editor styling tools + block level tools into one place – the same place, just like it is on the desktop – but it can't be in a popup.

Also, tooltips/popups suck, because we always had to check OS / browser combination, and for android even vendors, to determine where to display the tooltip, so that it won't cover the system copy/paste tooltips.

And that lead us to re-visit the idea of having a toolbar that floats above your keyboard on mobile device. The problem was iOS / Safari. On all devices & browsers soft-keyboards trigger window resize events, and shrink your viewport, so all you have to do was to align the toolbar to the bottom of the screen. done. But on iOS, it doesn't trigger resize events, and doesn't shrink your real viewport, so keyboard covers absolute bottom positioned stuff behind it.

To address this, browsers have a magical api called, Visual Viewport API. But iOS Safari's implementation was quite buggy. – until now! It seems like this is now in much better shape, so we decided to take on the challenge.

So now, all your tools are above the keyboard, and all the document actions are on the top = we no longer need the left sidebar!

So I proudly present to you, the new editor layout!

The New Mobile Editor

– You can see we moved all the document action buttons to the top, and all their pop-ups below them like this :

– And all the editor buttons to the bottom for easy access (they scroll left / right to reveal more tools) :

– All editor buttons follow the keyboard, and we also track keyboard height, so even if you have an international keyboard with more rows, or use emoji keyboard which is taller than usual, or use a bluetooth keyboard, which shrinks it down, this will be right above your keyboard bar, no matter how tall, and update/animate in realtime.

– finally, the sidebar is visible when you first launch Docs, to hint you it's there, and to allow creating new documents quickly, or jumping to recents / folders easily (even if you don't know you should swipe there) but hidden once you open a document.

Testing

We've released this in the beta channel minutes ago, so you can actually go ahead and give it a try! Please make sure your version is 714d8c6 after you install the beta app, and you're all set.

We would deeply appreciate your help with testing this especially on Android with Firefox and Chromium, since different vendors have different keyboard implementations, although we're 99% certain this is going to work on all devices, there's always that 1%... which could be something like samsung / xiaomi android running version 9, with an outdated Firefox, custom keyboard, combined with a browser extension etc etc. – there's no way we can test all these combinations / permutations.

But at least on iOS, this seems to be working amazingly, and we've even matched the animations of the editor tools to the keyboard itself. So on iOS the tools will spring bounce @ 60fps when you open / close the keyboard at native speeds. (or at least it should... so let us know if it jitters)

During the next few days, we'll be building some automated tests to check for potential edge cases. (like what happens if you have a windows 10 touch tablet, and press presentation mode, what happens to the toolbars etc etc) and once we've got all the bugs fixed, and test cases built, we're hoping to release this within a week or so.

I'm deeply sorry that this took so long, and I know it frustrated many users, but we had to solve 10 other problems before we could solve this one. Thank you for your patience!

Looking forward to hearing what you think! All the best, John

---

p.s. as a bonus, the editor now auto-scrolls as you type as well! So you can simply focus on typing! Let me know in #104 if you run into any issues with this or text selection or cursor positioning.

[BasilTomato]

Hello johnozbay, I have done some light testing, and it works fine for me. Thank you! Mobile: Xiaomi Mi A2 (Android One) OS: Android 10 (sec. update June 2021) Browser: Bromite 91.0.4472.102

[johnozbay]

Hey folks! Great news, this is now live! Let me know here if you experience any issues! Many thanks for your patience, understanding and help with all this ✌🏻

[ghost]

Hello John, nitpicking guy here👋 Great work as always! Two things I noticed:

1. top bar looks funky when locked It seems like the fading effect is missing here. Also, when you tap on the top bar while locked, the doc gets unlocked immediately, and it picks up an input. So depending on where you press, you unlock the document and open up the document info at the same time Idea for improvement: When a document is locked, the first input on the top bar should only remove the lock from the document.

2. divider missing Maybe I'm blind, but I think the divider is missing in the bottom bar.👀

Steffen

[johnozbay]

Hey Steffen! Both amazing catches!

1) We are working on a fix as we speak, and will push it out ASAP.

2) There are a few other tools missing (mostly block-level elements, some of which had a few issues on mobile before this update as well – So things like dividers didn't exist before either – due to the way text-selection works in mobile, they were getting inserted in random places) so we're still polishing up a few things and will add these in a week-ish or so. We wanted to get this out to collect bugs like the one you bumped into basically. (as well as edge-case things like what happens if you try to add a divider into a table cell etc)

Will ping this thread once the fixes are out! Many thanks!

[johnozbay]

Hey @SteffB44!

1 – Should be fixed now, give it a try and let me know! 2 – We've added a few more tools, more on the way. Give things a try and let me know!

Thanks a million ✌🏻

[dhda]

This is amazing on iOS! It would also be really useful on iPad when Cryptee is in a compact layout due to Split View or Slide Over. The sidebar takes up a ton of space in narrow views and makes it hard to use Cryptee in these modes. (can PWAs even access whether or not they should use a compact layout or are you limited to viewport size information?)

[johnozbay]

@dhda Glad to hear you're liking it! We only have access to viewport size information – but we know it's an iPad OS device, so we can infer whether if it should be compact or not etc.

That being said, the reason why we don't want to get rid of this on the iPad OS yet is because iPads treat Cryptee like Desktop (and treat your touch like mouse events – remember that whole iOS13 Desktop Class browsing thing), and as a result you get the full Desktop Cryptee experience.

This behavior is similar to Google Docs if you use it on your iPad, and in the interest of keeping cross-app familiarity we're not going to get rid of the sidebar on tablet/desktop size devices (i.e. Chrome OS etc are touch desktop devices too) to provide the full desktop experience where possible.

[dhda]

@johnozbay I’m not sure what changed (maybe I was stuck on an old version?) but this is working on my iPad now. Previously the narrow sidebar was permanently on the side of the side of the screen in compact layouts, but now it’s fully hidden with the editor controls on the bottom like on iOS.

Oh wait, I see. When Cryptee is started up in a compact layout it uses the iOS editor layout, but when it’s started in a full layout it uses the full desktop layout. Which is great in my book, it would just be even greater if it adjusted its layout on the fly when the window size changes.

[johnozbay]

So actually, that's an iPad feature / bug. When you launch Safari in small size (i.e. iPhone size) it reports itself as iOS Safari (and not iPad OS) and the system uses the touch browser and not the desktop-class browser™®©

– then when you resize to half-screen or larger, the browser doesn't reset (and perhaps can't reset) its engine, nor its reported user agent, and sticks with iOS.

– if you re-launch the app this time in full-size, then safari does report the desktop-class mode, and reports a different UA. But because it also restores the page's state from memory, and Cryptee's already running in the desktop-mode, we can't switch to / use the touch version until you relaunch the app / reload the window.

Long story short, it's an iPad OS Safari quirk – and there's no way around it.