DocumentHandler - Permanent Drawer Option

[OlofSvahnVbg]

Users have requested that the drawer should always be showing in desktop mode. Like this:

The lock option for the drawer menu should also be removed if the drawer is always showing. The same goes for the togglebutton, both shown below:

I suggest doing this by adding an option in admin for making the drawer permanent.

In the code, there already exists a variable named “drawerPermanent”. This name, in my opinion, suggests that the drawer is permanent (always showing). But this is not the case, as the variable controls the “Låt sidopanelen vara last vid start”.
So, maybe we should change the name of that variable to “drawerLockedOnStart” and add the new variable and name it “drawerPermanent”.

Or we could add the new variable and name it “drawerAlwaysPermanent” or something, maybe that’s easier.

[jacobwod]

Sure, but keep in mind that this will probably be a move away from the principle of Material Design where the drawer usually is a collapsable side panel (Google "material design dashboard" for typical use cases of the Drawer).

That's also one of the principles, as described in the official documentation:

On the other hand though, the same documentations says that

Standard drawers can be permanently visible or opened and closed by tapping a navigation menu icon. They can be used on tablet and desktop only. On mobile, modal drawers are used instead.

So it looks like it's okay after all, but please read up on the specification before implementing any changes.

[Hallbergs]

I agree that the drawerPermanent-setting should work as you described (a drawer that cannot be hidden). Changing drawerPermanent to drawerLockedOnStart and adding the new behavior to drawerPermanent sounds like the proper solution imo!

If/when you implement this, make sure to check eventual side-effects that might occur since drawerPermanent is probably stored in localStorage.

[OlofSvahnVbg]

So I added a new prop drawerStatic that turns on drawerVisible and drawerPermanent, while also removing the hide/display-buttons. It seemed easier than renaming, but if you bully me enough I can rename to the above mentioned variable names.

[Hallbergs]

Haha, as long as it is documented/commented on how they work somewhere it is fine!

[jacobwod]

BTW, just mentioning that the current solution is a mess. If I recall correctly, in addition to the settings you mention, we have another set of settings that specify the mobile-only behaviour. Make sure to check them out and – most importantly – test on small-screen devices.

[jacobwod]

I did some more testing and I'm not sure we can release this in 3.13. The thing is that if this option is enabled, there is now way to switch between the different content types in Drawer. Keep in mind that certain maps (like https://framtidsplan2050.halmstad.se) use Drawer to display contents from both the Tools menu and DocumentHandler. (There are also ideas about displaying legend graphic in a third tab in Drawer.)

So, enabling this option removes also these buttons:

Which unfortunately breaks certain map configurations and user are stuck in this view:

I can see where it would be desirable to use this option (e.g. don't allow hiding the Drawer) but still be able to switch between Drawer content.

What are your opinions, @OlofSvahnVbg, @Hallbergs, @jesade-vbg?

[jesade-vbg]

Ok, I see. We use this in ÖP & FÖP and we only have a few tools as control buttons and layermenu as widget. So we never use diffrent content types in the drawer as it is right now. If you have multiple drawer content it would probably be a good idea to be able to switch as you say..... yes. Only the "[X] button" and the Padlock should be hidden if I'm thinking correctly. Maybe theres more forgotten scenarios....

[jacobwod]

That's right, but it's not just the cross (X) on the button that closes - it's the entire button (where the icon changes to a cross to visualise that "that's what you see now, click to close"). Kind of a toggle button.

But otherwise that's correct: we should not hide the buttons, rather just hide the padlock AND remove the closing functionality from buttons. User should still be able to click the other button to show its contents in Drawer. Clicking on the active button should not have any action in this case.

On a second thought, I realise that this might be weird in configurations where only one button exists. That means user will see a button but it will not have any action at all. Could be ok, but could also be confusing. I think we need to test and see. If it's confusing, then the last solution I have is to hide the button (if only one is visible), otherwise show buttons but remove click functionality on currently active. 😄