Location Sharing Ended: Show the last shared location in the timeline.

[hoka99]

Your use case

What would you like to do?

1. After location sharing has ended, the location-share event in the timeline should show the last shared location.
2. Clicking on any expired location-share event in the timeline should show a more detailed map view, including the locations of all users who have shared their location, including expired location shares.
3. The Detailed Map UX should distinguish between active location sharing and expired location shares that are just displaying the last known location. Gray'd out avatars are last reported locations and not actively sharing ..

Why would you like to do it?

Currently, the timeline event just greys out and says live location has ended, providing no details about the location share.
It provides no benefit to just keep the location share timeline event grayed out. It becomes hard to gain context if you have a group of people sharing a location once someone has ended.

How would you like to achieve it?

1. Once a live share has ended, keep the last location visible in the timeline event.
2. Show last reported location in the detailed map view.

Have you considered any alternatives?

No response

Additional context

Creating a standalone ticket based off of element-hq/element-android#1274

Are you willing to provide a PR?

No

[mnaturel]

Hi @hoka99, thanks for the suggestion. I converted this issues into a discussion into the meta repository as it concerns all Element clients.
To give a quick answer, the fact the last location is not displayed in the timeline for a live location share was done on purpose for privacy concerns. In the final version of this feature, we don't want to keep any locations history of a live location.

[hoka99]

So live locations will only ever be MSC3672 ? It would be great to have the ability to toggle between MSC3672 and MSC3489 when doing a location share.

I believe Element would be the only chat app that implements live location sharing in this fashion where you are unable to see last location after a share. I think there is something to be said for keeping up with the industry standard features and expectations. This feels better suited to enable a "Incognito" mode when sharing location if someone wants the history deleted vs it being the default. It feels unexpected from a UX perspective that the map is no longer available for a user to see the last location.

I propose having a user specifically choose one or the other when sharing live location. Prefer to have the default being MSC3489 and choosing incognito for a specific share. Potentially a Map setting with a toggle for deleting location history after live location shares would be a great addition!

thanks for the feedback, looking forward to a community discussion!

[jtrees]

I agree with @hoka99 that the current behaviour is unexpected and inconvenient.

I understand the intent behind hiding the location and I commend always building features in a privacy-first manner. So first of all: thank you.

That said, in reality the current implementation offers little more than pseduo-privacy. At this point (after sharing the location), the data has already been sent over the wire, any other client could have stored it, chances are the user even saw it. Now it's simply a matter of whether the user still remembers or not.

It does little to actually protect the user's privacy but it does cause a noticeable inconvenience.

[lub]

I think there is something to be said for keeping up with the industry standard features and expectations.

FWIW the other solution I've used extensively before (Hauk) just displays a message that the location share expired.

[torrybr]

Very well said @jtrees

[lub]

Considering there is also the possibility to just send a static location I honestly don't understand the benefit of showing the last location of a live share after it ended.

When it's not important where I go after sharing my location, I can just send a static location and circumvent the overhead of a live share altogether.
When it's important where I go after I share my location I can send a live share, but then the last location in that live share after it ended is basically always worthless.

For example my typical use cases for a live share are

1. "I'm on my way, here you can see where I am already/approximate when I arrive"
2. "let's meet somewhere in the middle, here is my live location"
3. "let's share our locations in case we get lost so we can find one another"

In all of these the last known location after the share ended is at best useless and in the worst case confusing, because the recipient could think at a glance that the location is still somewhat accurate.

[torrybr]

Considering there is also the possibility to just send a static location I honestly don't understand the benefit of showing the last location of a live share after it ended.

I would like to hear from a dedicated UX person to get their input, but from my experience its about the UX of this feature. An opposing use case is using a room like a "Find My Friends" feature. If someone loses connectivity while walking home, my friends and I need to know where that last location is case they don't end up where they should be.

This about the context of the location share, not so much that I can just send another pin drop. When we discard the last location it feels disjointed and abrasive to the experience unless we indicate only these specific type of messages will disappear ( think wickr / disapearring messages on signal ). No message in the element ecosystem behaves with background disappearing and I would suspect most users are not expecting this behavior.

In all of these the last known location after the share ended is at best useless and in the worst case confusing, because the recipient could think at a glance that the location is still somewhat accurate.

I do not agree with this at all.

I did a little research in how other tools are handling this use case just to get feel for the current environment. As far as I'm concerned, the default should be whatever seems to be the status quo among other chat services, but is important to understand the ecosystem and behaviors in other apps if we want to appeal to a broader audience

App	Can Share Live Location	Displays Last Location After Live Share
Threema	🚫	n/a
Signal	🚫	n/a
Element	✅	🚫
WhatsApp	✅	✅
Telegram	✅	✅
Wickr	✅	✅
iPhone Find My Friends	✅	✅
Facebook Messenger	✅	🚫

WhatsApp

live_loc.mov

Telegram

telegram.mov

Wickr
(wikr disables screen recording on mobile app)

• recording from my laptop and doing a live share via my phone

loc2.mov

[lub]

An opposing use case is using a room like a "Find My Friends" feature. If someone loses connectivity while walking home, my friends and I need to know where that last location is case they don't end up where they should be.

FWIW when they loose connectivity the location share doesn't necessarily end. It only ends when actively stopped or the configured share time ends. Or is there some other timeout?

Also if they just lose connectivity (I understood it as losing mobile broadband/internet connectivity), they are probably not at their last sent location, otherwise they'd probably still have connectivity. =)

But I think I know what you mean, I also tried to write something similar in my examples.
I just don't think that the last location after the share ended is that useful instead of just not storing the last location in clients and servers indefinitely.

[jakewb-b]

Hi folks - I'm the product manager for the location sharing feature. First off, thanks for the helpful and detailed initial request and follow-up comments. The discussion above, and the assessment of similar functionality in other apps, is exactly the kind of thing we've been considering so having this input from the community is fantastic.

I'm not in a position right now to get this change scheduled in, but I am in favour of the functionality in principle. We did actually originally have as a requirement something similar to what is described in this issue, but the feature wasn't included in the launch of the labsed feature as there were some unanswered questions around it from a UX and privacy perspective.

For example, this issue suggests

Clicking on any expired location-share event in the timeline should show a more detailed map view, including the locations of all users who have shared their location, including expired location shares.

I wasn't confident that this was the right approach, as in larger rooms you could have dozens or hundreds of previously-shared locations, even though at any one time only a handful of people are live sharing, so the 'live' map view becomes cluttered and less helpful.

This could be mitigated by gradually fading out the last known points over a period of time. Alternatively, the last known location could be converted to behave like a static share, so that it has its own map view and does not appear on the overview. Weighing up those options, and others, is still something we need to do.

As discussed above, privacy was a concern in the original launch and we defaulted to the option-of-greatest-privacy but I agree with the comments that the privacy protection isn't all that great or necessary in this particular instance, and probably doesn't outweigh the inconvenience or unexpectedness. However, if we were to implement this I would want to visit the 'Stop Sharing' UI to make sure it was fully clear to users that their last location would still be visible, and perhaps to more clearly expose the fact that if they do want to remove it they can delete the event using the existing deletion UI.

We still have some work to do to get this feature out of labs, anyway, and this issue is 100% something we'll be considering when we do that.

[hoka99]

Thanks for taking the time to respond!! I apricate all the work you and team are doing to support community feedback!

I wasn't confident that this was the right approach, as in larger rooms you could have dozens or hundreds of previously-shared locations, even though at any one time only a handful of people are live sharing, so the 'live' map view becomes cluttered and less helpful.

I do agree with you on this and was not thinking about it in a sense of bigger rooms. This would quickly become a new ux problem