Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open and close AppNavigation #791

Closed
2 of 3 tasks
korelstar opened this issue Jan 1, 2020 · 8 comments
Closed
2 of 3 tasks

Open and close AppNavigation #791

korelstar opened this issue Jan 1, 2020 · 8 comments
Labels
1. to develop Accepted and waiting to be taken care of design Design, UX, interface and interaction design feature: app-navigation Related to the app-navigation component

Comments

@korelstar
Copy link
Contributor

korelstar commented Jan 1, 2020

Currently, the AppNavigation is always visible by default and can't be hidden. There is one exception: in mobile mode, AppNavigation is hidden by default and can be opened by clicking on the AppNavigationToggle (hamburger icon).

For the notes app, some people (@ma12-co and @jancborchardt) proposed to close the AppNavigation by default even on non-mobile mode, see the discussion around nextcloud/notes#413 (comment) and nextcloud/notes#364 (comment) . This allows us to use the AppNavigation in a better way.

In order to realize this, we need to do two the following things:

  • allow to close the AppNavigation in non-mobile mode
  • let the app control if the AppNavigation should be open or closed and provide actions for this
  • maybe change the design of AppNavigationToggle in order to make more clear what is behind this button (e.g. for the notes app it is the list of categories). Maybe the designers have of good idea on how to improve this?

What do you think about this approach?

/cc @jancborchardt @ma12-co @nextcloud/designers

@korelstar korelstar added 1. to develop Accepted and waiting to be taken care of feature: app-navigation Related to the app-navigation component design Design, UX, interface and interaction design labels Jan 1, 2020
@jancborchardt
Copy link
Contributor

jancborchardt commented Jan 2, 2020

To analyze it before we get ahead of ourselves – there’s basically 2 categories of apps:

  • Apps with an additional content list: Mail, Contacts (so far) and possibly Notes (if we go with moving to a 3-column layout). Here it could make sense to hide the AppNavigation by default.
  • Apps with only the AppNavigation: Files, Photos, Talk, Notes, Activity, Calendar, Tasks, Deck, Social, etc. Here it does not make sense to hide the AppNavigation by default.

So then thinking about the special cases:

  • Mail: This is a high-traffic app and if you use it for email you likely have it open all day. It would be ok to hide the AppNavigation by default for simplicity, but if you use folders a lot, it would be annoying to need to open it always, so it should stay open and remember the state.
  • Contacts: This is not often accessed as people tend to do contacts stuff on mobile or integrated into the OS, and even then it’s not a high-traffic app. It would be ok to hide the AppNavigation, but showing it is also fine.
  • Notes: Is for now a simple app layout with 2 columns. Moving to 3-columns would complexify it. For sure, and hiding the AppNavigation then makes sense.

So a crucial point is that we need to make sure that only apps for which it makes sense hide the AppNavigation by default. And that the state if it’s open or closed is remembered per app, per user.

Icon-wise, it should stay the list/hamburger icon as it is right now as this is a de-facto standard right now, no need to make this more complex.

@marcoambrosini
Copy link
Contributor

And that the state if it’s open or closed is remembered per app, per user.

Totally agree on this, but we'd need some back-end support for it, right?

BTW we could apply this reasoning to the right sidebar as well, in talk we currently allow the user to choose to always hide it for example, but if the user closes the browser tab or reloads the page, the user setting is lost and the behavior reverts to default (opened if enough width, closed otherwise).

@raimund-schluessler
Copy link
Contributor

but we'd need some back-end support for it, right?

You can just store settings in the userconfig table (per app, per user) similar to how we save settings in Tasks: https://github.com/nextcloud/tasks/blob/master/lib/Service/SettingsService.php#L62

@jancborchardt
Copy link
Contributor

BTW we could apply this reasoning to the right sidebar as well, in talk we currently allow the user to choose to always hide it for example, but if the user closes the browser tab or reloads the page, the user setting is lost and the behavior reverts to default (opened if enough width, closed otherwise).

Yes, the sidebar state should also be remembered. :)

@skjnldsv
Copy link
Contributor

skjnldsv commented Apr 3, 2020

And the AppNavigation would be collapsed by default even on desktop.

I remember looking at this with you @jancborchardt when checking how Apple was doing it, and they hide it by default on small windows, which is why we increased the breakpoint to 1024. But when enough available space they still show the Navigation by default, though you can still close it and the state is remembered.

Wouldn't that be better? Loading with enough space should not hide the Navigation by default. This goes also in the same direction as your idea to show the Sidebar by default if enough space nextcloud/server#7138

E.G. if I have a 4k monitor and I open the app, not showing the Navigation would not make much sense and would reduce discoverability I think :)

So I would be all in to just remember the state, (per app? I would rather not let each dev the task of implementing this?) and allow the closing of the navigation even on desktop view like #989 permit 😉


EDIT: this is what macos do (catalina):
They hide and show the appnavigation like we do for narrow width, but also allow manual toggle. Then it's remembered. Check all the boxes :)
Peek 06-04-2020 10-22

@jancborchardt
Copy link
Contributor

Wouldn't that be better? Loading with enough space should not hide the Navigation by default. This goes also in the same direction as your idea to show the Sidebar by default if enough space nextcloud/server#7138

Yep, absolutely still agree @skjnldsv – if there is enough space, we should show it by default. It could still be hidden and the state should ideally be remembered per-app.

@skjnldsv
Copy link
Contributor

skjnldsv commented Apr 6, 2020

Let's go for this!
@ma12-co let's leave the state remembering in a different pr, so it's not too much to review if that's ok with you :)

@raimund-schluessler
Copy link
Contributor

The AppNavigation sidebar can be close since a while already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. to develop Accepted and waiting to be taken care of design Design, UX, interface and interaction design feature: app-navigation Related to the app-navigation component
Projects
None yet
Development

No branches or pull requests

5 participants