Hi,
it would be most advantageous especially on smaller screens e.g. notebooks to be able to hide the left side panel showing the different calendars and therefore increasing the viewing area of main information window !!!
Such a toggle switch should be mandatory for all apps, showing a distinctive left side panel to achieve a common design goal and experience!
Sample can be found e.g. in the DECK app!
Regards, hitam4450
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
@nextcloud/designers I guess this is something we should do in the server?
Deck app basically always shows the burger menu similar to snap.js
That's not a bad idea.
cc @jancborchardt
Always showing the menu toggle would be a good possibility for all apps indeed. We try to automatically hide the left navigation on narrow widths already, but if people want to fully focus then having the toggle there is good.
What do you think @nextcloud/designers?
Any decision being already taken about the implementation of a mandatory toggle switch ?
Let me move this to the server repo then
What do you think @nextcloud/designers?
ping @nextcloud/designers :)
Seeing from the comments above, we basically agree. Just takes someone to implement it. :)
@skjnldsv I guess this is something we can move to the components repo?
Yes, we had a talk about this with @ChristophWurst
@juliushaertl Snap.js is part of the server though: https://github.com/nextcloud/server/blob/fd9ff581e2a92f65def3f5d3209c4328fb65416a/core/src/init.js#L216
@georgehrke not if you use the components :)
I think the following actions need to be taken:
does it make sense to open separate issues for each?
PS: I was about to file an issue about this, but then I found it here ;+)
- update the "guideline for developing (core) apps": you must integrate the toggle sidebar icon into your design
should be done automatically regardless you using the components or in server :)
@skjnldsv yes the hamburger icon should just show via components and server. But in some apps it is not well-integrated in the design, e.g. in calendar and contacts app the icon hovers over other content, slightly covering it.
(Maybe off-topic?)
[[Gnah can't post picture examples from.mobile]]
in calendar and contacts app the icon hovers over other content, slightly covering it.
Maybe check if there is not already an opened issue on calendar about this?
If not create one :)
Would also be nice for Talk, can we have this?
@nickvergessen Afaik this issue is mostly blocked by https://github.com/nextcloud/server/issues/16934 at the moment
Then we add a property to the Component allowing apps to say yes/no?
@nickvergessen I'd rather do it properly once and for all
Then we add a property to the Component allowing apps to say yes/no?
If an app has a navigation, and it’s below a certain width, then it should automatically work. Saying no should not be possible as it doesn’t depend on the app but on the screen size. Right @skjnldsv?
The "no" was regarding always show the toggle.
I'd rather do it properly once and for all
I think that on top of that we should have a prop to toggle the visibility of the collapse button regardless of the window width.
I think that on top of that we should have a prop to toggle the visibility of the collapse button regardless of the window width.
Nope, the idea is to show it all the time if there is an appnavigation. So No need for a toggle. The toggle is the appnavigation being here or not
The "no" was regarding always show the toggle.
Ah ok – for that we should also agree on something centrally though, not having this decided by individual app developers.
We had several requests to show the toggle permanently and it also will unify our mobile and desktop experience, so let’s go for that.
Also cc @karlitschek for reference.
I would like to remind of the discussion here, where a permanent toggle (i.e. shown also on non-mobile) was proposed by @jancborchardt and @ma12-co . That is why we have the issue https://github.com/nextcloud/nextcloud-vue/issues/791
Therefore, it would be nice, if the solution which is developed here, will fix also the above mentioned issue.
Most helpful comment
@nickvergessen I'd rather do it properly once and for all