search

tangrams / tangram-play

Text editor web app for Tangram scenes
https://tangram.city/play/
MIT License
94 stars 27 forks source link

Default to current location #226

Open bcamper opened 8 years ago

bcamper commented 8 years ago

I think it might be better to default to the user's current location (though I know that kicks off a permission request, so understand UX hesitancy) if there is no previous one stored. My reasoning is that the world view often doesn't look so great, either with the default style, or when you load examples (most of which were created with a higher zoom in mind). So I think current location at z15 or something would probably look better. What do you guys think?

bcamper commented 8 years ago

@louh @patriciogonzalezvivo

patriciogonzalezvivo commented 8 years ago

:+1:

louh commented 8 years ago

I just talked through the implications of this with @souperneon, so here's a summary of our thoughts.

One problem is that it would be wrong to assume that everyone will want to start on their own location immediately. As a style editor, the user's current location may not be particularly relevant to the task at hand.

Because it does kick off the permission request, a user may decide that the answer for now is "no." This will happen if a user expects that clicking "yes" will make an unnecessary redirection of her view, even if she plans on changing the view anyway. Then, if the user decides she want to use geolocation later, she has already denied the application from using that feature, which will cause geolocation to respect her original wishes (depending on the browser) and fail.

Meanwhile, there are these two problems which were identified:

Both are real issues, but I do think they create opportunities for other solutions:

(Just some ideas.)

The underlying problem seems to be this: for first time users of the application, first impressions are not insanely great.

If that's the priority, I think we can optimize for it, but I do think that geolocation requests for current location might not be the most useful or even friendly way of reaching that goal.

bcamper commented 8 years ago

Those concerns all make sense. While I don't know about the best near-term improvement, I do think this is a more important scenario than one would usually expect, because I've frequently encountered it as a sub-par experience when demoing to people.

On Thu, Nov 12, 2015 at 5:21 PM, Lou Huang notifications@github.com wrote:

I just talked through the implications of this with @souperneon https://github.com/souperneon, so here's a summary of our thoughts.

One problem is that it would be wrong to assume that everyone will want to start on their own location immediately. As a style editor, the user's current location may not particularly relevant to the task at hand.

Because it does kick off the permission request, a user may decide that the answer for now is "no." This will happen if a user expects that clicking "yes" will make an unnecessary redirection of her view, even if she plans on changing the view anyway. Then, if the user decides she want to use geolocation later, she has already denied the application from using that feature, which will cause geolocation to respect her original wishes (depending on the browser) and fail.

Meanwhile, there are these two problems which were identified:

  • The default world view doesn't look so great with the default style
  • The default world zoom level doesn't look great when you load examples

Both are real issues, but I do think they create opportunities for other solutions:

  • The default world view doesn't look so great with the default style. So, create a default style that looks great at the default world view.
  • The default world zoom level doesn't look great when you load examples. Maybe one of the "meta" information about scenes is a preferred zoom level for which it's designed, so when a user opens an example there's a prompt or an option to zoom the view to the scene's preferred zoom.

(Just some ideas.)

The underlying problem seems to be this: for first time users of the application, first impressions are not insanely great.

If that's the priority, I think we can optimize for it, but I do think that geolocation requests for current location might not be the most useful or even friendly way of reaching that goal.

— Reply to this email directly or view it on GitHub https://github.com/tangrams/tangram-play/issues/226#issuecomment-156254995 .

louh commented 8 years ago

@missinglink brought up the existence of a free / public geoIP lookup address over here: https://github.com/mapzen/leaflet-geocoder/issues/107

If it's a transparent process, that might be handy.

louh commented 8 years ago

Can I make one recommendation for this (and hopefully bring this issue to a resolution):

If a user has opened Tangram Play for the first time, and there is no previous view or scene, but then the user opens an example scene, then the view shall be set to an approximation of the user's current location at zoom 15 based on GeoIP if we have it, or NYC where the view is the best. This approximates the behavior of a "default / desired viewport" saved with scene metadata (but not expressly set in the scene YAML), but will not occur on subsequent example loading when a user already has a location and zoom in place.

This satisfies the requirements set above: (a) not requesting geolocation permissions unexpectedly (b) Tangram Play's "first boot" condition occurs at a low enough zoom to be meaningful while there are no render styles set for data (c) Loading an example scene immediately brings the best possible experience at a higher zoom

louh commented 8 years ago

Summary of follow-up discussion today with @souperneon @sleepylemur:

We discussed the consequences of having a "hidden" metadata that Tangram Play would use to show scenes at a desired lat/lng and zoom. This would help solve two problems: first, the problem described here, where scene files are loaded at the "default" view at a low zoom and isn't showing the goods promised in the screenshot; second, scenes like @burritojustice's Copenhagen map loading in the current view rather than the preferred view above Denmark.

However, this creates a secondary system circumventing Tangram's own built-in camera positioning and zoom syntax. As @souperneon points out, setting map view explicitly is a feature of many other map editors. Once a map view is set, it is clearer if it's in the syntax of the scene file, and its intent is declared to all consumers of the scene, not just in Tangram Play. We should be supporting this aspect of Tangram's syntax, rather than abandoning it.

The reason why we had considered not using position/zoom syntax is because of how Tangram Play repeatedly loads Tangram scenes. As a user pans or zooms the view in Tangram Play, edits to the scene will cause the view to reset each time. This was enough to consider a secondary system, but we've also realized that we could potentially override camera position/zoom just before the view is rendered. This turns the problem statement around: rather than create a secondary position/zoom syntax just to get around the issue of Tangram Play needing to reload scenes, we could instead remove the initial position/zoom syntax in Tangram Play for all reloads of the scene.

This would mean that for examples scenes that prefer specific views, it should be set explicitly in the Tangram YAML. (TBD: is Tangram position syntax overridden by Leaflet methods and/or leaflet-hash?)

If we fully support Tangram's position/zoom syntax, this is the outcome:

Thoughts? cc @bcamper

bcamper commented 8 years ago

I think it could be good to use Tangram's position syntax for the reasons you outline -- at least let's give it an attempt and see how it goes :)

We could add a flag to Tangram to ignore the scene's position/zoom on scene (re)load, this could be simpler than having Play try to intervene and "override" the values from the scene file.

patriciogonzalezvivo commented 8 years ago

Tangram-es was that same flag, https://github.com/tangrams/tangram-es/blob/master/core/src/tangram.h#L45

louh commented 8 years ago

Feature parity if this is introduced into Tangram JS?

On Thu, Sep 22, 2016 at 4:45 PM Patricio Gonzalez Vivo < notifications@github.com> wrote:

Tangram-es was that same flag, https://github.com/tangrams/tangram-es/blob/master/core/src/tangram.h#L45

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tangrams/tangram-play/issues/226#issuecomment-249022672, or mute the thread https://github.com/notifications/unsubscribe-auth/ACb1tNm60wEGjhxtIKn217Bwj8y6W0o9ks5qsujYgaJpZM4GgZx1 .