User cannot submit answer if network connection is lost

[PatriciaMoller]

While playing, even if connection is lost, the player can still open a question. But they cannot submit an answer.

Would it be possible to "pre-load" the questions, so they would be able to reach the end even if network is temporarily lost?

[kaimikael]

In principle I'm for bullet-proofing, but it does require that stored responses can be sent later, which may be difficult if the player quits the app before the connection is resumed. The player would then possibly be upset if points they thought they had gained are lost.

[PatriciaMoller]

Wouldn't some kind of "You're offline. Progress cannot be saved until connection is restored"-popup do something? At least then they get the choice to keep going, knowing the potential risk. And it doesn't completely halt them.

[pjotrsavitski]

We could possibly allow that king of approach. But that does change the overall game logic requirements (this means there is a need to implement that).

If we go with that, then every aspect should be well thought through before we even begin. This will take a lot of time and changing that over and over again is not an option.

We could also start using sessionStore or localStore to store the answers, then we could synch it to the server (we need to define what and how it should work).

The only issue I see is that there is no way to store the image responses. Those would just bee too big for the in-browser storage options.

Checking responses within the client is possible, although it would be loading information about correct and incorrect responses (but that should not be an issue).

Any badges/coupons and anything else would only be awarded once the information gets into the server. The system could only apply the logic once the informations becomes available to it.

If we decide to go with that, we should do that soon. We will soon be drawing the line to what radical changes could be made into the application (I did ask to mention to others that we would have preferred that to happen before September, but we could probably stretch it out until October).

One more thing to think about would be that if the device has lost connection to the server, then it would also have an issue with fetching the geolocation. If the game requires that, then it would still be unplayable (these might not be connected, but have a high probability).

[PatriciaMoller]

If the results of my Google fu is correct, then the difference between local and session storage is that session clears once the browser is closed while local has no set lifetime? If the player leaves the browser to try and configure their network settings, isn't there a chance that they might tab out of, and maybe even close the browser? I'm using the standard Samsung Internet and once in a while the tabs refresh (for exactly what reason, I don't know, if it's the page doing it, a session ran out, the phone freed up RAM on its own?) Whatever method reduces the risk of accidental loss of progress would seem the best.

What's the purpose for photos being uploaded to server? Can't they just be treated as just another any other photo taken with the phone's camera?

Yeah, Making a safe, difficult to exploit, offline option/work-around for coupons does feel a bit... redundant? In my experience here at Skansen, the Wi-fi is at it best a by the main entrance. I guess it would make sense to make the trails begin and end at spots where connection is rather certain, and have that as a general trail-making guideline.

For me, being able to answer all the questions of a trail with bad to no connection, in the case of school classes who might just want to get through the trail quickly along with their group (and imo shouldn't be seen as an "income" in terms of making them buy things through prize coupons anyway)

After the game has loaded, it can still get your location, even without network connection. It worked out well enough to be able to reach all the spots in the test Skansen trail. An issue would be that it can't load/update the map tiles. But the markers would still appear, right? Definitely not the best player experience, but knowing the relative location would still, by a stretch, make it playable.

[pjotrsavitski]

Yes, the difference between sessionStorage and localStorage is like you have stated. There are a few gotchas, though. Nothing lasts forever. Meaning that the OS/browser/person might decide to clear those values (localStorage) at some point in time (phone or tablet is running out of free space; user decides to clear caches and data storage; or anything else). But these should persist between sessions (closing the tab/window or even the browser).

Uploading to the server allows others (admins) to look at the answers later on, if that is needed. You probably do not have enough permissions to access that page. Storing the photo is the main reason for "photo" type of question being there.

Well, if we do not require the data connection to be present at all times, then we should state that and change the logic of the current code. We should also have some way to determine if the connections is (probably) there or not. Changing colour of some UI element could be sufficient (I see no point in showing that the same way the GPS/positioning signal being lost is).

[PatriciaMoller]

As long as it is stored long enough for them to either get their connection going again or until they finished the trail, it sounds safe enough to me. Of course depending on the trail and how effectively they play, shouldn't be more than a couple of hours up to the rest of the day. Is there any risk it could be wiped that quickly without manual input?

Having the connection status incorporated in the UI's colors sounds pretty cool! That wouldn't require any extra menus or else that could clutter the screen. Is it possible to change the color of the player icon/the red dot?

When would the game be checking for connection, it is only during the submission or at any other time as well?

A spontaneous idea:
The player tries to submit answer, but lost connection. The game saves it locally.
For the first time it happens, the game notifies them that "Connection lost. You can keep playing, but may lose progress when you close the page."
While connection is lost the player icon and the submit button change color (say, gray for player icon, orange for submit)
When the connection is back, their colors return to normal.

[pjotrsavitski]

I suppose the risk is minimal to none-existing (if they decide to remove the browser app, wipe out history or anything else, then it can not be helped).

Yes, changing colour of the player icon is possible. We can also change the contents of the InfoWindow. So that it would show what is going on. We could also use the same approach with the "Geopositioning lost" situation. The solution should be more or less general.

If we want to display some warning to the user during periods on inactivity, then I see no other way but to add some timer that would be trying to make a "ping" request to the server from time to time to see if the response is successful. Another way would be to setup the persistent connection (WebSockets would be once example), but running that would be a waste of resources in this context.

The submission would not even be happening, just writing to the in-browser storage (it will be a bit more complicated).

That kind of approach would be quite possible. Yet we would still need to periodically check for connection status, in your case we would need to start doing that only when we determine that connection is lost and until a successful one happens.

One more solution would be to change the background colour of the top menu to indicate certain things. Not sure what the best approach would be.

[PatriciaMoller]

(I still haven't been able to see the Geopositioning Lost" message) But it would probably be the smoothest way to go about it, it feels consistent. (For example, Pokémon Go uses the same red bar on the top to message "No GPS Signal" and "No Network Connection".) However the first time might give a pop up, so the player knows. As long as the player is proper informed that they still can keep playing even if the bar is there, then it would only be a reminder of the risks rather than disruptive.

The "ping" is sound more reasonable. Since gameplay doesn't need the constant connection, it feels unnecessary to invest in having it

[PatriciaMoller]

An example of the popup informing about lost connection. This would only show up the first time :

Illustration found Here

[pjotrsavitski]

I will be working on the positioning a bit later. It seems that the way the API behaves across Operating Systems and Browsers is not very consistent with regard to positioning loss. I am planning on storing the latest position with the timestamp and would show the position lost element if current position is older than a minute or so.

The image is looking fine to me, but it will only make sense if we implement the playing offline feature.

[kaimikael]

Note here for when and if this gets implemented:
Status indication should not rely on colour alone, but also the shape of the UI elements in question (could be something like fuzzying the outline of them if the geometry cannot be easily changed).