nextcloud / neon

A framework for building convergent cross-platform Nextcloud clients using Flutter.
Other
130 stars 31 forks source link

adaptive design ideas #307

Open Leptopoda opened 1 year ago

Leptopoda commented 1 year ago

While tackling #294 I noticed that our Adaptive design isn't optimal rn. Mainly that we should use NavigationRail instead of a crippled drawer.

I decided to make use of flutter_adaptive_scaffold wich is a flutter official package implementing M3 design AdaptiveLayouts.

I made a quick POC wich can be found at https://github.com/Leptopoda/nextcloud-neon/tree/cleanup/ResponsiveScaffold (notification counter missing).

Now this showed me that our current design isn't really adaptive and responsive (wich is one of our goals). The AppBar is fairly useless on non mobile views when using multiple accounts. We show the user avatar two times :woman_shrugging:


Having a look at the M3 design: https://m3.material.io/foundations/layout/understanding-layout/overview https://m3.material.io/components/navigation-rail/overview

My idea is to utilize the dual pane design to show a collection of items on one side and an opened item on the other. Imagine a list of notes/news_articles on the left and the opened article/note on the right.

If we do it right we wouldn't need the BottomNavigationBar and AppBar as view related info from the app bar will be shown on the top of each pane and the bottom bar items in the Navigation rail.

The only problem I have is our usecase of having multiple "apps" with thier own NavigationBar. While I found one reference in the spec that each pane can have their own BottomBar and AppBar I doubt this would look good. Imagine a NavigationRail on the side not related to the view and a half width BottomBar with some items.

Ideally I'd like to replicate the below screenshot where we have a NavigationRail per app that can transform into a BottomNavigationBar on small views. The only problem with this is that we wouldn't have a place for the app/account switcher as the NavigationRail would be app specific.

I'd add those in a HamburgerMenue that opens a drawer on small and medium screens (see below) and sectioned always expanded drawer an large screens (again see below).

ld4wxkhh-3p_whats new_2x

I'm no designer but what do you think of this idea? Can you find a better way that adheres to M3?


We'd need to change AppImplementation to hold all the extra information and also find a way to talk to the AdaptiveScaffold from the apps as they need to manipulate the secondary views. I'm also sure this will help a lot when I tackle #282 as a lot of the layout changes might go hand in hand with this one.

provokateurin commented 1 year ago

I think it's a good idea. Please send some screenshots :)

Leptopoda commented 1 year ago

A small POC for the notes app. Yes the FAB is missing and there are a few edge cases I didn't show :shushing_face: The drawer in the AppBar will be used to switch apps/accounts on small and medium screens and be merged with the expaneed drawer on large screens.

And somehow the apps will need to communicate all this back to the main app (it's currently only in neon_news and we'll need to define nice interfaces)

https://user-images.githubusercontent.com/25266387/236870489-4193b097-1867-4534-8c76-0d3aed23e324.mp4

provokateurin commented 1 year ago

Oh I love it! :heart: The resizing animation is a bit wonky but that should be fixable.

It would be really nice to define this in a generic way that makes it easy to implement.

Leptopoda commented 1 year ago

The resizing animation is a bit wonky but that should be fixable.

I'm not that sure about that :/ the lib provides an AdaptiveLayout widget and a AdaptiveScaffold. They do what they sound like and the animations are defined on the latter. Sadly as the lib is still in it's early stages it doesn't support customizing the animations yet. FABs are also not supported at this stage.

But I'd rather work around it than having to implement AdaptiveLayout in a custom widget.

It would be really nice to define this in a generic way that makes it easy to implement.

I don't know yet but ideally the apps should provide a list of Pages and their NavigationDestination (icon + label). Then the main app (neon) would lay them out in a ResponsiveScaffold (so nothing for the apps to implement).

Ideally we'd intercept the Navigator calls and automatically push them onto a new screen or into the second pane.

Leptopoda commented 1 year ago

https://github.com/flutter/flutter/issues/126509

So I don't forget it.

provokateurin commented 1 year ago

I think for the desktop layout it would be nice to have the apps navigation similar to how it works on the web UI.

Leptopoda commented 1 year ago

That's a nice Idea and simplifies my code quite a bit (we won't have a list with nested app routes and app views).

Leptopoda commented 1 year ago

should we try to mimic the NC style or use a material TabBar? https://m3.material.io/components/tabs/overview

Also I think this should only be used on Desktop and not on tablet as havng both a navrail and a tabbar doesn't look so good

provokateurin commented 1 year ago

I would stick to M3 components

provokateurin commented 3 weeks ago

@Leptopoda could we try to implement these ideas? Especially for Talk on desktop it would be awesome to have a 2-pane layout with the chat list and the current chat

Leptopoda commented 3 weeks ago

I would prefer to first cleanup the logic of talk (migrating it to a repositoryand bloc steucture) before tackling major new features in the UI.

But I'm always open to review PRs :)