Onboarding UI updates to the goTenna app - Cast your vote now!

This is great thinking, @dbfish. I’ll have to hash out what’s technically feasible with @Rahul_Subramany, but I like the user experience you’re imagining. It’s simple, low-friction. :+1:

1 Like

Currently a green checkmark indicates if a message was received by another gotenna device, but not if that device is paired to a phone, or if the user opened the conversation and read the message. In every other app on every other smartphone, a message checkmark means it was ready by the other party, so I suggest to follow that convention in gotenna with a little more granularity given two devices are needed to read messages (gotenna and phone). In 1/1 messages, it is important to know if a phone is still on and receiving messages, or if it died or went out of bluetooth range, and your messages are not being read, if you are pinging an unpaired relay now instead of an actual person, etc, given connectivity is your own network and communications can be in emergency situations where this matters. This is low priority but I think a valuable long term addition to the UX.

Suggested changes:
White checkmark - message delivered to destination gotenna
Black checkmark - message delivered to paired phone
"Read " (like iMessage) user opened conversation on phone and has optional “send read receipts” feature turned on (off by default to reduce radio traffic).

By the way, good job on the additional pop-up explanation when the first undelivered message warning happens, that is a welcome UX update for newer users.

3 Likes

YESSS. But I don’t want to make @michaelryap look bad. The pop-up was really just an easy UX band-aid @Rahul_Subramany and I came up with (before @michaelryap joined our team this summer) to temporarily address what needs to be a deeper UX fix and which is still on our to-do list — and will be in @michaelryap’s capable hands.

@dbfish Thanks for all these ideas, keep 'em coming!! I like the idea of different/new checkmarks that go beyond delivered or unconfirmed. :wink:

I will note however that read receipts would clog our network, especially with all the ACKs/NACKs involved with meshing on limited public spectrum. We do want to keep overhead in our transmissions limited to essential features so we can scale the mesh network as much as possible!

3 Likes

@michaelryap @danielagotenna @Rahul_Subramany So did you decide to go with Option 1? :slight_smile:

1 Like

@femmesh We did! Would you consider helping us testing a tappable prototype in the future?

1 Like

You and I have similar visions for the app, @dbfish. Some of the message indications you suggest are technically constrained at the moment, but, that doesn’t mean @Rahul_Subramany and I won’t be considering them. We are currently working on the UX
for Pinging at-large—would you consider helping us test a prototype in the future?

1 Like

@michaelryap I’ve been a beta tester since v1, yes of course! And you can roll out granularity of delivery confirmations only for single hop messages - since this would be great for v1 users as well.

I actually had some issues testing last night where a message would say it was not delivered, but then found out they did show up on the recipient’s phone, that was a first. Testing at the edge of range. But what was a bigger issue is how undelivered messages queue up using a timing mechanism when trying to test. If you send 3 messages quickly, it will start a timer on the first, and only attempt the 2, 3rd after the 1st fails, which is up to a minute later.

Maybe an option to change the delivery attempt timing, since when I’m testing, it works or it doesn’t and I don’t really want it to retry unless I change position, but in actual use, it should retry. I’d love to hear the thinking behind how the timing and message queuing was developed.

2 Likes

@dbfish the timeout for each 1-to-1 message is ~38 seconds. This is a conservative estimate that allows for an acknowledgement to be received after multiple retries over multiple hops. Without this time out, there is a higher probability of message loss, especially when multiple people are communicating at the same time.
As we improve our Mesh protocol, this timeout will be significantly reduced.

2 Likes

I have experienced this as well. Sent messages that show undelivered but were received at recipients phone. I realize this could be due to loss of communication on its way back.

@dbfish Awesome, good to know, and thanks!

@Rahul_Subramany thoughts on these false-negatives?

@Mark yes false negative acknowledgements can show up in rare cases where the RF path between you and the recipient changed before you received his/her acknowledgement.
As we improve our Mesh protocol, the probability of false negative acks will reduce. Stay tuned!

2 Likes

We really need a separate app / mode just for range testing, with a giant “Ping” button, waits 3 seconds for delivery, then turns the screen red “NOPE!” and stops trying. Spending a lot of time waiting as all the test messages queue up and fail.

3 Likes

If you have 2 testers participating, Shout messages will be the easiest way to test 1-to-1 range.

1 Like

I’m testing relay node placement on a 20 foot antenna on the roof and out of bluetooth range. Although I could pair it, disconnect, then review shout messages later, although timestamps won’t work in that case. And also bad practice to spam the shout channel, you should know better :wink:

3 Likes