humhub
Support for multiple HumHub Sites
Maybe, in a first time, we could save the previously URLs entered in the form, and show them as a suggestion to avoid having to type the hole URL each time we switch instance?
And if we can go back to the instance URL form without login out, we could switch instance quite easily.
Of course, it's not perfect, mainly for notifications, but if it's simple to develop it can help the time beeing.
Hey @marc-farre, as you suggested, I've prepared a quick demo.
Users can switch between instances using a dropdown list in the TextFormField. When they are connected to an instance, a swipe gesture on the WebView will reveal a back button for quick navigation back to the opener. Reconnecting to logged-in instances is instantaneous (current session inside WebView). Push notifications are configured per instance, so there's no problem here, and the redirect should continue to work. My concern is only how we can indicate to users that this exists, considering the hidden nature of the back button.
https://github.com/humhub/app/assets/10835179/62315a51-85dd-4beb-b02c-7603842f431d
@luke- any thoughts?
@PrimozRatej Thanks! That's awesome! Maybe it will solve https://github.com/humhub/app/issues/139 ?
Perhaps we could add an entry in the account menu, next to the "Logout" entry, called something like "Return to form URL"? Of curse, this entry will only be shown in the mobile app (we should have a way in PHP to know if Humhub is currently executed in a browser or the mobile app).
Another idea: adding a "Clear" button on the URL form to quickly remove the current URL and access to the URLs dropdown list?
@marc-farre I like the idea of offering an additional menu item "Back to app" or similar when using the app. We can recognize and display this.
But then we have to somehow collect currently logged in HumHub instances and offer a logout (clear) option.
Hey @luke - we could use the JS channels for this and a custom app header, as you mentioned, and the logic will stay on the web side, I like the idea here.
Regarding saving currently logged-in instances, I don't think that would be necessary. Instead, we can simply save the instances that the user has ever connected to, not necessarily logged in.
If the issue you see involves push notifications (those will be sent to the user if the user hasn't logged out of a particular instance), when the user clicks on a specific push notification, they will be redirected to that instance, and then they can log out.
We can save the connected instances on the mobile device itself in local storage.
@PrimozRatej Do I understand correctly that we only save the instances that have ever been entered?
But the user is only logged in to one installation at a time and should therefore only receive push notifications from this one.
Later, we can expand the feature to allow multiple "Logged In" instances in parallel, including push notifications.
Users can switch between instances using a dropdown list
@PrimozRatej Do you plan to release this new feature? It would be very useful! Thanks!
@marc-farre We should definitely get push notifications for one site to work reliably first. Before we start with multi-site support :-)
Hey @marc-farre, @luke-, do you think now is the time to support this feature?
@PrimozRatej I would say we must focus on:
- iOs app
- custom branded app
- reliability of the application (testing)
@luke- ?
@marc-farre @PrimozRatej
I think that with multi HumHub support, we have a clear argument in favour of apple app approval.
Here is a mockup masterpiece of how I would see this feature.
- Maybe we can also add a count of notifications
What you think? Should we focus on this topic? (After Branded Apps.)
If it helps for the Apple store and it's not too much work developing it, then yes of course, it would be great to have. But I don't know if it's a big value compared to the browser navigation in the eyes of Apple (it's similar to multiple tabs).
For the UX experience, I feel like it's not intuitive to switch from an instance to another. I think we need somewhere a dropdown accessible when browsing HumHub.
If it helps for the Apple store and it's not too much work developing it, then yes of course, it would be great to have. But I don't know if it's a big value compared to the browser navigation in the eyes of Apple (it's similar to multiple tabs).
Perhaps we can find another feature that is quicker and easier to implement. The multi-instance mode is not that easy to implement.
For the UX experience, I feel like it's not intuitive to switch from an instance to another. I think we need somewhere a dropdown accessible when browsing HumHub.
- If multiple instances are added to the app, the "Instance selection" should always be displayed first at startup.
- It should be possible to switch to the "Instance selection" via the account menu.
@luke- I would suggest to position Switch HumHub Instance either under My Profile OR above Logout
Under My Profile
Above Logout
(Icon would be changed as in the screenshot above)
I share with you how https://www.mightynetworks.com allows switching instances on their mobile app. They call the button "Switch network" which might be more intuitive to general public than "Switch HumHub instance". They use a sidebar offcanvas (sort of modabl box on the side, see https://getbootstrap.com/docs/5.3/components/offcanvas/):
@PrimozRatej I have sent you a pm via Element to discuss possibilities of UI elements to use. After your validation I would post it to this issue.
Please find the suggested design solution below.
The idea:
- Show up to three
last loginsto avoid cluttering the interface - when clicking
add networkyou will be guided through the existing flow Need helpshould still be visible on the first front screen
@PrimozRatej I know that I already asked you if it was possible to display the fav-icon. But do you maybe know whether you can also show the logo of the network in the app preview? I guess so, but please confirm :)
https://github.com/user-attachments/assets/9909b885-08cf-4c05-ad21-aeb148bb0c28
@Eladnarlea, I can access the favicon through https://community.humhub.com/manifest.json. I assume the network's logo is different, so I think we would need to add it to the manifest or make it accessible through some kind of open API.
We would likely need to add the badge number value to that same API as well. Or use silet push like discused here https://github.com/humhub/app/issues/52
@PrimozRatej @Eladnarlea We should only work with information here that is available in ‘manifest.json’. (Square Icon) This is the only thing that is reliably available for every HumHub installation. Unfortunately, we cannot add custom attributes here as the format is fixed.
We have to add the notification count later via the SilentPush notification.
@luke- @PrimozRatej That's fine. So only the icon will be visible instead of the whole logo - right? @PrimozRatej Do you need new mockups for this, or will that not be necessary?
@Eladnarlea, there's no need. If there are any changes, we can address them in the second iteration.
@PrimozRatej In older versions, once logged in to a HumHub instance, it was possible to display the app homepage form (to enter another HumHub instance) URL, by swiping right from the left edge (or clicking on the Android return button). On v1.0.110, it displays "Do you want to exit an App?". So we need to sign out each time we want to switch to another HumHub instance.
@marc-farre, @luke-
This is the current impl.
https://github.com/user-attachments/assets/af215d4a-0658-43ff-a278-4d40e25931c3 Once the user navigates to a specific instance, there is no way to return to the opener page, where they could then navigate to another instance from their list.
The idea I had here is to implement a JS channel, similar to what we did for isHideOpener. When the user logs out, we navigate them back to the opener page. This works, but it requires the user to log out in order to return.
To allow the user to stay logged in while still switching between instances, we would need a 'Switch Instance' button. I was thinking this could be placed in the menu.
When this is clicked, the JS channel switchInstance will be triggered, and we can redirect the user to the native part of the opener. This button will only be shown for isMobile users.
NOTE: To maintain backward compatibility, we do not want to show this button to users with an older version of the mobile app that does not yet support 'Multiple HumHub Sites.' For this, I can add a custom header isMultiInstanceSupport to ensure the button is only displayed when this is set to true.
I think that's perfect.
The isMultiInstanceSupport will be useful for white labelled apps, because for most of them we will set it to false.
@luke- do you approve the idea? Should I implement this new menu item for 1.17-beta.3? Name: "Switch network"? Other idea?
Do we keep Last logins: or should we change for My networks:?
The
isMultiInstanceSupportwill be useful for white labelled apps, because for most of them we will set it tofalse.
Ah, I forgot about white-labeled apps. I think we should support a "Switch Instance" button on all instances, including white-labeled ones. This is because in case users use both the opener app and white-labeled app for same instance.
For white-labeled apps, we can add an additional header: isWhiteLabeled.
The logic would then be:
If isWhiteLabeled == true: Do not show the "Switch Instance" button.
If isWhiteLabeled == false and isMultiInstanceSupport == true: Show the "Switch Instance" button.
Do we keep
Last logins:or should we change forMy networks:?
I think My networks: it's better.
A thought on HideOpener State
Currently, the app has the “hideOpener” state. In this state, when you press “Back” or open a closed app, the opener is no longer displayed.
If we now allow multiple instances, does it really make sense to continue having this state?
"Switch Network" in User Account Menu
If we decide to add this menu item (might also make sense without the “hideOpener” state - see above), I like the idea with the headers to determine when to show this option.
@marc-farre I would like to implement the “Switch Network” in the FCM push module first.
For v18, we could extract general mobile app components into a core module mobile-app. What do you think?
@luke- Yes, that sounds good.
We had a discussion with @PrimozRatej about the isWhiteLabeled idea and though we don't need it (the isMultiInstanceSupport is enough).
For the hideOpener, I'll leave @PrimozRatej answer.
Ok. By the way, we already have detection for whitelabel apps via https://github.com/humhub/fcm-push/blob/master/helpers/MobileAppHelper.php#L66-L80