conversations + multi-tab apps, not really a good combination?

[jeanluc]

Wondering how others deal with this limitation.

The purpose of conversations is to be a mid-point (in terms of data visibility and memory usage) between short-lived contexts (such as requests) and much longer ones such as the session. All is fine as long as the user stays in a single browser window tab. Conversations are born and die and sometimes they are nested. The user interacts with the site, oblivious to this concept.

Consider the case when the user does something with the site, then opens a link starting a second conversation in a separate tab and for a while works in this second tab. At some point he returns to the first tab and does something. If the first conversation has expired, the user is greeted with an error (or is politely told he has been inactive in this window). A crude way to avoid this is to increase the conversation timeout, but this is not memory-efficient. Another crude way is to use the same conversation for both use cases. In both cases, the conversation is no longer used as a conversation, but like a session.

The concept of being inactive in a tab is not user-friendly either. Users understand the concept of session expiration because that's tied to any interaction with the site. But the conversation expiration is less friendly. After all, they may expect not to see such errors as long as they interact with the application.

I'm curious what strategies you have in dealing with this...

[asookazian]

Consider the fact that most users are not accustomed to the concept of conversation timeout b/c most other frmwks don't have conversation concept.  So it's actually better if a background conversation doesn't happen or timeout otherwise you have training issues to deal with.

You can increase the conversation timeout for background conversations to closer to the normal timeout for sessions (e.g. 20-30 min's) to make this experience more seamless to the user.

In practice, I have not found too many use cases that require multi-tab (and thus multi-LRC/workspace) designs/implementations.  These use cases are typically for comparison purposes and that does not occur too often in the real world.

[jeanluc]

Arbi Sookazian wrote on May 15, 2010 23:54:


You can increase the conversation timeout for background conversations to closer to the normal timeout for sessions (e.g. 20-30 min's) to make this experience more seamless to the user.

I can indeed, but this negates the main selling point for using conversations and not sessions. Furthermore, it still doesn't solve the problem. While working in a different tab will continue to keep the session alive, the conversations not used for a while will time out, giving errors.

In practice, I have not found too many use cases that require multi-tab (and thus multi-LRC/workspace) designs/implementations.  These use cases are typically for comparison purposes and that does not occur too often in the real world.

I'd argue that they do happen a lot more often. It only takes a wheel-click to open a page in a new tab. I do that with GMail messages and with a lot of web sites that I visit, including with this forum. Same with travel booking sites, I'd like to explore several air ticket options simultaneously. Even Seam's own documentation gives this example (multiple bookings in different browser tabs), see section 1.6.3.

It'd be useful to have a concept of auto-refreshed conversations, where you could mark which conversations you want to keep active, even if unused, while the session is still valid.

[kragoth]

I just have a few questions about how you would manage such a request.

How would you know that the tab was closed? So they middle click and get a new tab and start working but close their old tab. How is the framework supposed to know that the first tab is gone and it can let it time out?

Secondly, let's assume we can keep it active. How is it any different to the session now? Let's say the user spends the rest of the day in the second tab, are we going to keep the first tab's conversation open all this time? If so then you might as well have just extended the conversation timeout to be the same as the session time out.

Thirdly, if your conversation timeout is so low that the user is experiencing conversation timeouts in their first tab while working in their second tab then your conversation timeout is probably just too low. This would mean that a short phone call would also cause them to lose their conversation anyway.

Last but not least. Let's assume that all these points that I have brought up are not a factor in your application (which may be the case. :) ) Then write your own manager to fix it. From a high level I would imagine something like this.

Have a map of userSession -> converations in some Application scoped component.

Have a listener that detects a request/post and touches all the conversations belonging to that user's session. (I'm not going to work out how to do this go look at the Conversation class there's something about this in there)

Now you need to know when to delete conversations from the map. How you work that out will probably be up to your application and how it works.

***Alternative Solution****
I really have no idea if this would work. And I'm not going to go write an app to try it out :P.
But what about having an ajax poll on every page in your system that just keeps your conversation alive? Then when a tab gets closed the polling would stop and thus the conversation would time out. This would really only work though if the browser continues the polling even if the tab does not have focus. Which I'm not sure if the browsers do.

At the end of the day though I think personally this is just a fancy way of extending your conversation timeout. If a user is going to spend 30mins in the second tab then maybe the first tab should timeout. Having a longer timeout even up to two hours would only be an issue in an environment where you are dealing with a large number of sessions where users are using multiple tabs. How likely is this in your application? I think there's a lot of questions to be asking here before assuming that a keep alive solution is required.

With regards to other sites that appear to do this. I would be very surprised if they are using conversations at all. My guess is that most of the time there is just a session timeout and everything else is done with request params.

[jeanluc]

Tim Evers wrote on May 18, 2010 01:47:

How would you know that the tab was closed? So they middle click and get a new tab and start working but close their old tab. How is the framework supposed to know that the first tab is gone and it can let it time out?

It cannot, of course. Where the line is drawn between overall memory usage and user inconvenience depends on the particular needs of each site. In our case, it's a site for business users so the latter has a higher priority.

Secondly, let's assume we can keep it active. How is it any different to the session now? Let's say the user spends the rest of the day in the second tab, are we going to keep the first tab's conversation open all this time? If so then you might as well have just extended the conversation timeout to be the same as the session time out.

Yes. Ideally, I would be able to set the conversation timeout per conversation (not as a global setting), because within the app I know which conversations are worth of being kept alive. I don't want to keep the insignificant ones around, just the worthy ones (such as the results of complex queries).

Last but not least. Let's assume that all these points that I have brought up are not a factor in your application (which may be the case. :) ) Then write your own manager to fix it. From a high level I would imagine something like this.

Have a map of userSession -> converations in some Application scoped component.

Have a listener that detects a request/post and touches all the conversations belonging to that user's session. (I'm not going to work out how to do this go look at the Conversation class there's something about this in there)

Now you need to know when to delete conversations from the map. How you work that out will probably be up to your application and how it works.

Yeah, we'll be doing something similar to it.

Thanks,
jl

[muhviehstarr]

We used META-Refresh and / or AJAX-Requests to keep the conversation in an hidden tab alive.

So in this case if the user really closes the tab, no such AJAX-Request or META-Refresh would happen and so the conversation wouldn't be refreshed and timed out.