Chat with AI

[tobiasKaminsky]

• Android
• iOS

Edit:

• Add most used assistant types on top (3 max) and a (…) button to select the rest
• Assistant opens straight into Chat, and auto opens keyboard.
• For each type we should support different fields and inputs
• Input fields should be at the bottom for mobile
• Input and output should be the same screen (add loading views when generating output)

• Chat should look like chat UI on web
• Show this footer in chat

Chat Endpoint: nextcloud/assistant#394

TODO:

• Assistant Improvements #82 (comment)
• Improve navigation
• Chat
• Improve rest of the types

[alperozturk96]

@mahibi @tobiasKaminsky Maybe we want to have it for the Talk app as well, we can do it in common lib?

[jancborchardt]

FYI @kra-mo and also @marcoambrosini regarding Assistant design.

For the first version, it would make sense to mirror whatever we have on web, of course in a Material way:

Chat list	Chat detail

[alperozturk96]

Notes for discussion:

Accessing the conversation list from the left panel is generally expected and a common behavior. However, on Android, we currently use a Drawer menu in that same location.

We should discuss the best approach for implementing this e.g.:

Should we disable drawer menu access on the Assistant screen? If so, how would users access the drawer elsewhere?

Alternatively, should we add an additional button on the top bar to open either the conversation list or the drawer menu so that the conversation list would be the default one?

Demo

Screen.Recording.2025-11-04.at.11.34.18.mp4

Topbar

[jancborchardt]

@alperozturk96 what would the recommended pattern on Android be here?

Often the pattern on Android is that if you use a different entry of the bottom bar, the context changes completely. In our own app for example in Media and Favorites, you also don’t see the account switcher. Whereas we currently use the left sidebar more in a way to put stuff that doesn’t fit in the bottom bar.

If we think of the sidebar more like in the web, it could show context-dependent actions. Then in the case of Assistant, it would be the history.

What do you think @kra-mo?

[alperozturk96]

@jancborchardt I think we should avoid using two navigation components within a single screen. I’ve shared this earlier when implementing the Bottom Navigation Bar. Material Design Guideline.

The Navigation Drawer is primarily intended for app-level navigation rather than displaying large lists of items.

---

Since the conversation history could include over a hundred items, using a navigation drawer would not provide the best user experience.

A more natural and scalable approach would be to replacing the navigation drawer we have right now in the assistant screen with a Conversation Screen. When users swipe from the left or tap the top bar item, this screen could slide in smoothly, similar to how other LLM apps handles it.

Then, this would not be a drawer, but rather a separate screen transition. Component is HorizontalPager

For example:

WhatsApp.Video.2025-11-04.at.16.12.16.mp4

[jancborchardt]

A more natural and scalable approach would be to replacing the navigation drawer we have right now in the assistant screen with a Conversation Screen. When users swipe from the left or tap the top bar item, this screen could slide in smoothly, similar to how other LLM apps handles it.

Then, this would not be a drawer, but rather a separate screen transition. Component is HorizontalPager

@alperozturk96 right, that makes a lot of sense of course!

Then also in the long run we should probably conform to the Material guidelines and only use one main navigation paradigm. And that would probably be the bottom bar, which then should have one last entry to show whatever can’t fit, similar to how we do it on iOS?

[alperozturk96]

@jancborchardt On Android Assistant tab will be bottom-sheet as well right just like iOS? Currently it's a screen.

[marcoambrosini]

@alperozturk96 IMO it should stay a screen