create share landing page design

[kfarr]

REWRITE

• instead, not complicated
• just basic viewer mode to see the scene
• still needs OG tags for the preview
• instructions on how to move around
• CTA for "Remix"
• URL -- should this be different URL so that the opengraph info is generated server-side? The URL can also indicate to open in viewer mode instead of editor mode first
• ideas: 3dstreet.app/share/uuid or 3dstreet.app/#view/uuid or 3dstreet.app/view/#[UUID] or 3dstreet.app/view/#[UUID]
• does that mean 3dstreet.app/edit/[UUID] is the path for scenes in edit mode? Does that mean we need to change the URL path from edit to view when switching in between? does that mean 3dstreet.app/ shouldn't resolve by itself?
• what's the least change from what exists today? just that new share links resolve to viewer mode?
• or what if there is simply /view/UUID that redirects via javascript to /#view:uuid

---

User story:

• As a user viewing a 3DStreet scene that was shared with me directly, via social media, email, or another social network, I want to see a preview of the scene on that platform before I click, and then when I click I want to see a preview of the scene, the title of the scene, and information about the experience that I'm about to have if I click "play" on the scene.

Technical

• We need to provide a page with an image preview embedded in meta tags
• 3DStreet doesn't work predictably well on mobile devices
• Users may be confused when entering a 3DStreet scene without context

Therefore:

• We create a "share landing page" design that is a scene preview and satisfies the technical requirements for open graph (sharing image and metadata on social media) but does not actually load the scene
• The "share landing page" includes a big play button, very similar to a video player, that will then load the scene (either inline via iframe or as a normal link traversal to open a new page in the same window)

Additional considerations:

• Users visiting this page will have little or no familiarity with 3DStreet / its tools -- it may help to provide context / info / links / design that helps the user understand what they are seeing / what will happen when they press the play button
• Unfortunately mobile doesn't work so well so we may need to include messaging to users on mobile devices that they may want to open this on a different device
• Should this page place the user in Viewer mode or Edit mode? Perhaps this will eventually be configurable by the person sharing the scene?

[kfarr]

new proposal

server-side rendering for scenes at url of 3dstreet.app/scenes/sceneID/

urls:

• server.com/scenes/[SCENE_UUID]/ - "happy path" canonical root for scene viewing (and editing)
• server.com/scenes/[SCENE_UUID].json - json representation of the scene

Therefore the URLs https://server.com/#/scenes/[SCENE_UUID].json and https://server.com/scenes/[SCENE_UUID]/ should be functionally equivalent for end-users.

Method: use some sort of cloud function with html template. Server-side rendering can apply scene-specific settings by interpreting json scene for given ID. Could use a template system like django / jinja. v1 can just be a huge quote literal in a javascript firebase cloud function with 1 variable inserted for the URL of the preview of the scene for social media purposes, with backup if not available.

advantages:

• it can serve social media images for social preview - also try video and animated gif
• for renderer or other scene setup options that must be specified at the start of page load and cannot be changed later via javascript / json configuration

disadvantages:

• server-side rendering is a pain no matter what
• users who look at their URLs may be confused by the similar but separate URL scheme

considerations - what could go wrong?

• what if I have a URL link from current scheme, how will that work when new scheme is live?
• https://server.com/#/scenes/[SCENE_UUID].json
• what if I go to a new URL in current system? server.com/scenes/[SCENE_UUID]/ how will that load?