Moments will be accessed from mobile devices (either inside browsers, or inside wrappers like WebViews or iFrames).
Your UX/UI must be flexible enough to adapt to different screen sizes and ratio either by hiding or re-arranging some elements.
Usually, people on a mobile phone multitask: they switch from one app to the other to perform other activities like texting, posting on social media etc.
Your Moment is a Website. When websites are put in background mode, or when the screen is locked, the mobile OS will perform some activities to increase overall performances and battery-life. In particular it will:
Interrupt the websocket connections
Throttle timers and intervals
To address these issues, it's important to detect when a Moment was put in background. The easiest way to achieve it is to use the Page Visibility API (https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API).
Other methods might be less effecting and more difficult to implement. Exampled are:
periodically check the current time agains a reference value
Remember to listen for error events coming from the websockets.
In addition, you can listen to the
window['ws-offline'] event or register a listener at
The moment runs in a webpage, and the page can be reloaded anytime.
It's important the Moment can pick up from where it left before refreshing. Some examples:
If the page reloads during a countdown, the countdown should not restart from the beginning (unless that is the intended behaviour);
If the user is in the middle of a multi-step form, it's best if it could pick up from the latest step rather than the first one.
If the user has filled in a shopping kart, the items should stay
The Moment (WebApp) you create will likely be accessed by a crowd of users at the same time.
We make out best effort to provide fault tolerance and horizontal scalability when the number of requests grows, however you should make your best effort to:
Keep the user state as small as possible: don't store unnecessary or redundant information if not needed.
Keep the ws communication to the minimum: especially, when broadcasting, do it wisely.
The userstate updates channel doesn't scale well: assume there are 10.000 users updating their state 100 times a minute. This will lead to 100.000 notifications being sent to the subscriber. Assuming all the 10.000 users have subscribed for the updates, all of the 10k users will get the 100k updates. A rule of thumb is to have only a master user (usually the result page) to subscribe to the state updates.