[Web App] Suggestion to replace Top Left "Back" function
Answered/Implemented
I'll like to share on this quickly: https://app.gametize.com/project/1. The Top Left "Back" option brings the page back to app.gametize.com itself.
1. I'll like to suggest to remove the "Back" button altogether because very often players on this page would come into a Project Page directly. This "Back" option is in fact misleading and can bring the player into a state they are unable to return to.
2. To address the problem of how app.gametize.com users might need to navigate back to the home screen, I will suggest to instead allow another tab to open whenever a project is being selected, or a "pop-up" will appear that can be exited with a top X icon. 
3. The other use case would be the page will be embedded in a page like https://www.drukasia.com/bhutan-challenge/, and both "Home" or "Back" will not make sense. 
The other embed example:
-
Notes from Lee Chuan Xin:
Adding a note here that we used to have the full back button title here, but we standardised all back button titles to say "Back" on mobile view, because of a lack of space in giving the full title especially on smaller screens. This is especially so in places like Topic view, where sometimes the Project title (which the Topic view when going back should reach) is very long (as opposed to just saying "< Project") and it is unreasonable to expect the full Project title there.
If you open app.gametize.com/project/1 in desktop, it does say "Home" correctly. Going forward, perhaps it will be easier to just not show any title in the Back button for mobile view, ie. mobile it will just show "<". It will be easier to assume "<" means we will take you to the page before (if we cannot expect where you are coming before), or a level before (such as Project before Topic if you are in Topic view), as opposed to giving you the certainty it is just "Back" like clicking Back on the browser. -
The challenge I am facing now is there is a potential lead is embedding one of such pages in their website. As such, the "Back" button navigates the player out of that Project, and they would not know how to come back to the project. This may potentially happen to many more users in other use cases, if they share that url like app.gametize.com/project/xxx. I can however think of 3 ways to solve this:
1) The default skin for all web-views should remove the "back" button altogether. It may be good to use a different url, e.g. web.gametize.com/<projectname> or web.gametize.com/p/<id> (p/s I like this URL better too). This URL will be the only one that is "shared" as well as embedded (as in our embed code). app.gametize.com can continue to work too, and the skin with a "back button" can remain - e.g. for Gametize Lite especially.
2) Keep the Back button. Whenever <Back> is being tapped on, the browser checks for the state; if it is inside an App environment, e.g. Hybrid App Container, it redirects back to app.gametize.com (or any other main app)
3) Keep the Back button. All Projects will be opened in a new tab when accessed from app.gametize.com. While it is bearable if using app.gametize.com as a website, it may not work in a Hybrid environment. We can try this on Gametize Lite too.
Thoughts? -
Amanda I would like to bump this up especially because I am aware projects have been actively embedded, especially a collaborating event @ignatius is working with. The back button is worrying especially because there are no way to come up to the Project page once that is clicked on.
Tentatively, I would like to recommend a quick interim fix to have the user directed to "My Games" if "Back" is tapped on; that way, at least the users can still tap back on their Project to find their way back (still a logical workflow too). -
My alternative suggestion:
Option 4: When folks want to embed projects through app.gametize.com in their IFRAME or hybrid apps without a back button in the Project view, I can create a URL parameter just for that: eg. app.gametize.com/project/xxx?embedded_project=true. In the future "embedded_project=true" will be the go-to parameter to use only for embedding. The usual app.gametize.com flow (where embedded_project=false) will be business as usual.
When embedded_project=true, I will just save this parameter in the local storage to remind the app not to ever show the back button when in the Project view. Using the local storage is persistent to the browser. Thus, if they ever want the back button again so they can navigate through the normal app.gametize.com flow once more, they just need to modify the URL on their end (to use "?embedded_project=false") in the URL bar or their IFRAME / hybrid app container.It will be easier than the alternatives you suggested because:
Option 1: Deployment on Ensheng's end. Also, double-work on my end for upstreaming, whenever we launch new features. I will need to upstream for both app.gametize.com and web.gametize.com. My Option 4 only involves allowing the existing app.gametize.com to recognise and accept the "embedded_project" parameter.
Option 2: Involves the use of user agent strings. User agent strings are not very backward and forward compatible, eg. iOS or Android can update their hybrid app browsers one day and the previous user agent strings may not work anymore. Will involve a lot of work on my end to continually monitor updates on the iOS and Android front, and I will only rely on user agent strings as a last resort (for instance, Gametize web bottom bar interface in the latest iPhones with their own iOS bottom bars, and only because I foresee this interface will stay for future iPhones).Option 3: It will not work on the hybrid app environment, as you said. Our hybrid apps are designed to recognise "target='_blank'" and open the link in the separate (their default) mobile browser. The flow will be clunky on both the regular web and hybrid apps.
This Option 4 consideration is made with the priority to minimise changes to the existing app.gametize.com flow as much as possible, while affording this new edge case of not displaying a back button in minority circumstances. By going with Option 4, I can deliver this as early as early next week.
-
This has been rolled out for app.gametize.com. To test, open the 2 links below in separate windows:
(1) https://app.gametize.com/project/167?embedded_project=true
(2) https://app.gametize.com/project/167 (no embedded_project flag, so by default it is false)
When embedded_project=true,
- The player / visitor will essentially be "scoped" or locked within the Project, and this means:
- No back button to return to the home view
- After logging out and then signing back in, they should return to the Project. This is in contrast to the default behaviour of returning to the home view upon logging out and signing back in.
Some technicalities:
- This uses sessionStorage, which essentially lets the flag persist for the entire browser page session. This flag will not be lost after logging out, because it takes into account the browser page session instead of your user API session.
- It will persist through page navigation, until you close the window or tab.
- It is also tested to persist on refreshing the page, using the in-app refresh functionality or manual refreshing using your browser button or hotkeys.
- Thus it should work for IFRAME embeds.
- However, this flag will be lost when you attempt to open any of the links (such as to the Topic page) in a new window/tab. The flag will persist in the current window, but will be lost in the new open window.
- Whenever you want to revert to the original app.gametize.com experience, simply set embedded_project to false. Say, using https://app.gametize.com/project/167, simply add ?embedded_project=false at the back to become https://app.gametize.com/project/167?embedded_project=false.- If no URL parameter for "embedded_project" is found in the URL, it will simply take the previously set value in that particular tab/window. This is why navigating to other pages afterwards without the embedded_project flag in the URL still works.
- For more, read https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage
What's left:
- Updating the Project embed URL in the Share Project window to include the ?embedded_project=true flag.
Please sign in to leave a comment.
Comments
7 comments