Periodic Refreshing for the Browser-Server Dialogue

How long will the refresh period be?

The refresh period can differ widely, depending on usage context. Broadly speaking, we can identify three categories of activity level:

Real-Time interaction (milliseconds)

The user is actively interacting with the system, and his input relies on the server's output--for example, a chat user needs to see what others are saying, a trader needs to see current prices, or a game player needs to see the state of the game. Here, the interval could be as low as a millisecond on a local machine or local network, or perhaps be 20-100 milliseconds on a global network.

Active monitoring (seconds)

The user relies on the server state for work outside the system--for example, a security officer watches sensor displays for suspicious activity, or a manager occasionally watches the fluctuation of sales figures during a particular window of time. In some cases, timeliness may be critical, making subsecond responses desirable. In other cases, a few seconds is sufficient feedback.

Casual monitoring (minutes)

Some applications are designed for the user to leave in a window or separate browser tab and view throughout the day. The information does not change often, and it's no drama if the user finds out a little later. Prime candidates here are portals and RSS aggregators. Refresh periods of 10 minutes or more are often acceptable for such content. A manual "Refresh Now" mechanism is worth including where the refresh period is longer than a few seconds. It can relate to the entire application or to specific components.

Sometimes, the best solution uses multiple Periodic Refresh cycles in parallel, each with a frequency reflecting the user's needs. An interactive wiki, for example, might update news headlines every 10 minutes, online statuses of other users every minute, and content being edited every second.