Improving the onboarding of new servers into the ecosystem of mobile clients

Launching the Android, at the same time we deprecated the Cordova was tough. I wanted to share, after completing 2 months having the Android app in the store (and a huge amount of new users), what are the most frequent pains they’re having and how I think we can handle it.

The list points most for the bad experiences that our users had. There were of course some bad reviews saying we’re lacking features, but this is something we knew would happen. The topics I wanna talk about are things I honestly didn’t expect from server administrators and I think we can do better to the next ones.

No support for WebSockets: many reviews were pointing to errors related to not having WebSockets support. This is super required for both applications to work. Both iOS and Android rely on WebSockets to get updates and of course that if the user is using Rocket.Chat on the web, he will never notice, because Meteor has it’s own fallback way to handle it. IMHO we must act on this and warn the admin users when WebSocket is not enabled on the server. The Wizard is a major entry point now for us to do that. Just saying to the administrator that WebSockets aren’t enable would reduce drastically the bad experience some of them are having on the apps.

“Store_Last_Message” setting disabled: we leaved it false by default, and we already discussed about it here. The Android app is already handling correctly when the setting is false and the iOS will support it too when the new layout come out. But that doesn’t mean it needs to be the default experience. We need to act on it, make it true by default as soon as possible (at least in our hosting, where we have much more control?).

Other improvements

Number of unread messages: this was a long discussion between me, Gabriel and Thiago. I’m bringing this subject here because I still think it’s important and I’m want to try to change our mind about it. :slight_smile:

The thing is: people that are using our mobile apps are expecting to have an experience similar to WhatsApp/Telegram now in terms of interface. But there’s one tricky thing that we’re no doing: the badge that we show to the user is only showing the number of unread messages that are related to the user. So, for instance, when you see #general in unread state, you’ll hardly see how many messages are unread. I don’t see how this can be good to the mobile user, because some of the chats are going to have a number (like DMs or some channel/group that mentioned him) but others don’t.

My point is: let’s show the badge to any message that’s unread by the user on the channel/group/dm. I think this will provide a much better experience when using the mobile apps.

Update data in background: I really wanted to start this discussion with you guys. I know we’ve touched this subject but never changed anything on this. Let me give you guys some clarification on how the app networking/data sync works so we make sure we’re on the same page: the iOS/Android apps now do not sync in background. What we currently do is: when the app opens, we ask for the changes on the room/subscriptions list, and when the user opens a chat, we fetch all the new messages from that room. That’s not even close to the experience that we want our users to have. I’ve couple of suggestions for us to investigate (and I wanna hear your feedback on them):

  1. We can update the data on the app via silent push-notifications. The push can contains all the information from a message and then we can store this data on the app and show later to the user from the database.
  2. We can have a “sync” API that the apps fetch from time to time to get the changes since the last update.
1 Like

First off. Perfect medium for this. Some things must be explained in a very detailed way like this.

I agree. Warning them early on would help a lot with this. I think we have several checks we could add to this so it wouldn’t just be a websocket check.

Thanks for the reminder. Hosting it will now be on by default for all new deployments:

I think we definitely should continue down this path for everyone. Especially if we are pivoting to be comparable to whatsapp / telegram and not just slack.

Ignoring any potential technical hurdles. What about huge channels? Does telegram show number of unread on the outside? Whatsapp is the only one that comes directly to mind that shows total. But whatsapp is very much direct message and direct message groups. Where the intention would definitely be to get every single message unless muted.

I think some of our users want to consume this way… maybe when we add direct message to multiple people in the future this will solve?

Does whatsapp do something like this? Because i’ve noticed some how in low signal areas it says: “You may have unread messages”

Almost like an empty push came through and it can’t fetch in the background to get the message and generate a notification with contents.

Only worry for me would be… our gateway would quickly start chewing through our quota. Some how up until now we haven’t hit it. But if we do this feels like we would be accelerating this.

This seems like in conjunction with a push notification that needs to actually alert them, that this might work. :thinking:

Slack / Discord do something similar to this even in their desktop site. They do this primarily for connection lost. But they seem to ask for events that were missed since last connection.

1 Like

Thank you very much!

I think we can say something like: +99 instead of the raw number for that kind of situation. What do you think?

I believe they’re using their own MQTT service in background, but that’s a bunch of extra work to everybody for now. Silent push is a very simple solution that would not require many extra work for now. There’s no limit for sending push notification in terms of quantity (refer here)

Yes, both things would be perfect :ok_hand:

1 Like

A follow up from here… Wouldn’t an unread indicator also make them expect to be actually notified of each message?

I think we might be headed for MQTT service. Depending on how things play out. I’m also a bit worried about the server side implications of needing to send an alert on every single message.

If we switched to silent push notifications for all normal alerts and let the app perform a sync and show the notifications, as well as maybe in background sync?

I’ve been wanting to bring something like this up for a while. Because we have people worried about the fact that technically we can see every single push notification message if we want that passes through our gateway (of course they can turn off message… but then they aren’t as useful)

I don’t think so. At least, that’s not how Telegram/WhatsApp are doing. I think notification is another thing and is not related to the badge (at least I can say that from my usage).

Just adding here another huge confusion from a user related to the Store_Last_Message setting and the badge not happening in channel/groups: iOS 3.0 released.